Re: NAT64 ios issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Johan:


This has been resolved.  The problem was due to our FreeSwitch server sending INFO messages to the client every time it tries for a session update (audio to video and vice versa). We added some logs to see what was causing the content length to go beyond 1000 bytes, and were surprised to see the buffer being passed as an argument to calculate_new_content_length function. Here it is:


v=0
o=FreeSWITCH 1494550159 1494550161 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 32392 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:32393 IN IP4 XX.XX.44.166
m=video 30442 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
INFO sip:104@[2001:2::aab1:f863:a967:5bab:f24]:62007;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP XX.XX.44.166;branch=z9hG4bKDFgHZDr6Kpvep
Max-Forwards: 70
From: <sip:103@xxxxxxxxxxxxxxxxxxxx>;tag=SQ8ervgXBXrXF
To: <sip:104@xxxxxxxxxxxxxxxxxxxx>;tag=cqaxfyCBeIKml95wpBVFbzZkWTQ0QuFB
Call-ID: mTLalvJyCpgsLz-AbJcwMx3JxcKuKh8m
CSeq: 106955541 INFO
Contact: <sip:103@xxxxx.44.166:5060;transport=tcp>
User-Agent: VoIP-PBX
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/media_control+xml
Content-Length: 175

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<vc_primitive>
<to_encoder>
<picture_fast_update>
</picture_fast_update>
</to_encoder>
</vc_primitive>
</media_control>

We modified the function to get exact length of SDP body. I don't know if this is a problem others would experience and not sure you want to patch your code. Anyways, attaching the patch file.


48a49
>     int len;
50a52,53
>     char* body_end;
>
52a56,60
>         body_end = strstr(body_start,"INFO sip");
>         if(body_end != NULL) {
>             len = body_end - body_start;
>             return len;
>         }


Regards,

Girish


From: pjsip <pjsip-bounces@xxxxxxxxxxxxxxx> on behalf of Girish Gopinath <gopinath_girish@xxxxxxxxxxx>
Sent: Wednesday, May 10, 2017 7:46 PM
To: JOHAN LANTZ; pjsip list
Subject: Re: NAT64 ios issue
 

Hi Johan:


Thank you for the reply.  Added logs below from an attempt to switch from audio call to video. The content length is never more than 1000, but in the logs it says 1253. Looks like I'm missing something here.


Thank you,


Girish


15:20:08.575   pjsua_core.c  ....TX 1398 bytes Request msg INVITE/cseq=11944 (tdta0x12284d200) to TCP 2001:2:0:1baa::4225:2ca6:5060:
INVITE sip:mod_sofia@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
Max-Forwards: 70
From: <sip:104@xxxxx.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:103@xxxxxxxxxxxxxxxxxxxx>;tag=5Zv34Z5NQ22QF
Contact: <sip:104@[2001:2::aab1:292f:d2ac:6e72:35f5]:58184;transport=TCP;ob>
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: VoIPUA-1.0 iOS-10.3.1/arm-iPhone8,1/iOS-SDK
Content-Type: application/sdp
Content-Length:   668

v=0
o=- 3703398596 3703398599 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
s=pjmedia
b=AS:352
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 0 99 9 96
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:64000
a=rtcp:4001 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:99 speex/32000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=video 4004 RTP/AVP 97
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:256000
a=rtcp:4005 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--
15:20:08.781     pj_nat64.c !.ipv6_mod_on_rx
15:20:08.781     pj_nat64.c  .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.781     pj_nat64.c  .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.781     pj_nat64.c  .SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:104@xxxxx.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:103@xxxxxxxxxxxxxxxxxxxx>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

15:20:08.781     pj_nat64.c  .***************************************************************
15:20:08.781     pj_nat64.c  .Scanner syntax error at
15:20:08.781     pj_nat64.c  .Error: Parsing of the incoming INVITE/200 OK failed at . Leave incoming buffer as is
15:20:08.781   pjsua_core.c  .RX 375 bytes Response msg 100/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:104@xxxxx.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:103@xxxxxxxxxxxxxxxxxxxx>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

--end msg--
15:20:08.789     pj_nat64.c  .ipv6_mod_on_rx
15:20:08.789     pj_nat64.c  .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.789     pj_nat64.c  .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.789     pj_nat64.c  .SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:104@xxxxx.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:103@xxxxxxxxxxxxxxxxxxxx>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:mod_sofia@xxxxx.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP4 XX.XX.44.166
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

15:20:08.789     pj_nat64.c  .***************************************************************
15:20:08.789     pj_nat64.c  .Extracted ip4 address as XX.XX.44.166
15:20:08.793     pj_nat64.c  .Extracted ip4 address as XX.XX.44.166
15:20:08.794     pj_nat64.c  .Extracted ip4 address as XX.XX.44.166
15:20:08.795     pj_nat64.c  .Scanner syntax error at
15:20:08.795     pj_nat64.c  .Current Content-Length is: 358 and new Content-Length is 1253 .
15:20:08.795     pj_nat64.c  .Updated content length needs more bytes than old one, we must do expand and copy. TODO
15:20:08.795     pj_nat64.c  .We have successfully parsed the INVITE/200 OK until EOF. Replace rx buffer. pjsip will now print the modified rx packet.
15:20:08.795     pj_nat64.c  .Host in Contact header is XX.XX.44.166
15:20:08.796   pjsua_core.c  .RX 1914 bytes Response msg 200/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:104@xxxxx.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:103@xxxxxxxxxxxxxxxxxxxx>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:mod_sofia@xxxxx.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP6 2001:2:0:1baa::4225:2ca6
s=FreeSWITCH
c=IN IP6 2001:2:0:1baa::4225:2ca6
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP6 2001:2:0:1baa::4225:2ca6
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--

15:20:08.797          sdp.c  ....Error parsing SDP in line 15 col 0: Success
Assertion failed: (ctx.last_error != PJ_SUCCESS), function pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.
(lldb)




From: JOHAN LANTZ <johan.lantz@xxxxxxxxxxxxxx>
Sent: Wednesday, May 10, 2017 7:00 PM
To: Girish Gopinath; pjsip list
Subject: Re: NAT64 ios issue
 
Could you send an example of the sdp you are processing?

I assume this simply means that previously your content length used for instance 3 chars, something like 980 and then after the manipulation content length is more than 1000 bytes meaning we need 4 characters instead of 3. IIRC my sdp´s were quite far away from the limit so I added that scenario as a corner case that I did not implement. I think you will be able to fix it yourself if you spend some time on it. I am going to spend a little time on this code this week but I can not promise I have time to add this scenario so I suggest you start by trying to fix it yourself (and contribute the fix back to GitHub if it works :-)

Johan

From: Girish Gopinath
Date: Wednesday, 10 May 2017 at 15:08
To: pjsip list, Johan Lantz
Subject: Re: NAT64 ios issue

Updated content length needs more bytes than old one, we must do expand 



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

Attachment: pj-nat64.c.patch
Description: pj-nat64.c.patch

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux