[Spce-user] problem with Fragmented udp SIP Packets.
Jaime
jaime at tnagroup.cl
Wed Feb 28 11:45:09 EST 2018
Hi Robert, thanks for the info, I upgraded my sipwise to the latest version 5.5.3 and the problem continued. Performing a debug on the side of our provider, he check that the ACK for some reason responded to the IP 127.0.0.1?
finally we apply the WorkAround for the Audiocodes equipment and start receiving the ACK's correctly.
https://www.sipwise.com/doc/mr5.5.3/spce/ar01s04.html#_audiocodes_devices_workaround <https://www.sipwise.com/doc/mr5.5.3/spce/ar01s04.html#_audiocodes_devices_workaround>
Thanks for your help
Jaime
> El 23-02-2018, a las 7:01 a.m., Robert Cuaresma <rcuaresma at telcon.es> escribió:
>
> Hi Jaime,
>
> I had the same problem few month ago... The problem was that the carrier send me a very long call id. I solve the problem deleting the name of the extensions on the PBX. This, reduce the SIP packet length and may solve your problem (temporally). You can disable not used codecs on pbx too.
>
> I hope can help you.
>
> Saludos,
> Robert Cuaresma
>
> El 21/02/2018 a las 17:39, Jaime escribió:
>> Hi All,
>>
>> currently we use mr4.5.6 and works very well, but I have experienced a problem with incoming calls from a carrier.
>>
>> The symptom is: the incoming calls from the Carrier to our Sipwise are cut at 30 sec.
>>
>> I have seen that they are cut because in the SIP messages we have not received the ACK on the carrier side, which generates the cut at 30sec per timeout; and this is due to what I could say that the response sent to the Carrier: "SIP 200 OK” is fragmented because it is greater than 1500 bytes.
>> As I can see in the following wireshark:
>> 4 5.539257 x.x.153.35 x.x.158.76 IPv4 1516 Fragmented IP protocol (proto=UDP 17, off=0, ID=9a96) [Reassembled in #5]
>> 5 5.539274 x.x.153.35 x.x.158.76 SIP/SDP 197 Status: 200 OK |
>>
>> Already raise this problem with our supplier, however I would like to ask if it is possible on our side (from the SipWise) to modify and reduce the size of the SIP packet response of the "SIP 200 OK", because I see that the answer and solution on the side of our carrier can take a long… (also my provider does not have SIP over TCP ;-(
>>
>>
>> Thanks in advance.
>> Jaime
>>
>>
>> In the SIP dialog I can see that multiple SIP 200 OK are sent but never receive an ACK:
>> =============================
>> |Time | x.x.158.76 |
>> | | | x.x.153.35 |
>> |0.000000 | INVITE SDP (g729 g71 |SIP INVITE From: <sip:955400000 at x.x.158.76:5060 <sip:955400000 at x.x.158.76:5060> To:<sip:56228697777 at x.x.153.35:5060 Call-ID:7fabe7551f00-449edbc9-13c4-65014-9579e-6a8779fe-9579e CSeq:1
>> | |(5060) ------------------> <sip:56228697777 at x.x.153.35:5060Call-ID:7fabe7551f00-449edbc9-13c4-65014-9579e-6a8779fe-9579eCSeq:1||(5060)------------------> (5060) |
>> |0.002799 | 100 Trying| |SIP Status 100 Trying
>> | |(5060) <------------------ (5060) |
>> |0.128765 | 180 Ringing |SIP Status 180 Ringing
>> | |(5060) <------------------ (5060) |
>> |5.539274 | 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |6.018953 | 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |7.019163 | 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |11.017827| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |15.018051| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |19.017300| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |23.018126| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |27.018019| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |31.018112| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |35.017920| 200 OK SDP (g729 tel |SIP Status 200 OK
>> | |(5060) <------------------ (5060) |
>> |37.524346| BYE | |SIP Request BYE CSeq:10
>> | |(5060) <------------------ (5060) |
>> |37.531809| 200 OK | |SIP Status 200 OK
>> | |(5060) ------------------> (5060) |
>> =============================
>>
>>
>> And the packet SIP 200 response, that is large than 1500 bytes.
>>
>> =============================
>> Session Initiation Protocol (200)
>> Status-Line: SIP/2.0 200 OK
>> Message Header
>> Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e;did=7ad.8182;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=QVhMNGZ6N0p3S2lvUmEsOS4UXyMZFBFgNyQuHyITWVli> <sip:127.0.0.1:5062;lr=on;ftag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e;did=7ad.8182;ice_caller=strip;ice_callee=strip;aset=50;rtpprx=yes;vsf=QVhMNGZ6N0p3S2lvUmEsOS4UXyMZFBFgNyQuHyITWVli>
>> Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e;ngcplb=yes;socket=udp:x.x.153.35:5060> <sip:127.0.0.1;r2=on;lr=on;ftag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e;ngcplb=yes;socket=udp:x.x.153.35:5060>
>> Record-Route: <sip:x.x.153.35;r2=on;lr=on;ftag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e;ngcplb=yes;socket=udp:x.x.153.35:5060> <sip:x.x.153.35;r2=on;lr=on;ftag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e;ngcplb=yes;socket=udp:x.x.153.35:5060>
>> From: <sip:955400000 at x.x.158.76:5060> <sip:955400000 at x.x.158.76:5060>;tag=7fabe8014538-449edbc9-13c4-65014-9579e-21b12904-9579e
>> To: <sip:56228697777 at x.x.153.35:5060> <sip:56228697777 at x.x.153.35:5060>;tag=181C5B95-5A8502570005257D-46C9F700
>> Call-ID: 7fabe7551f00-449edbc9-13c4-65014-9579e-6a8779fe-9579e
>> CSeq: 1 INVITE
>> Record-Route: <sip:x.x.158.76:5060;transport=UDP;lr> <sip:x.x.158.76:5060;transport=UDP;lr>
>> Via: SIP/2.0/UDP x.x.158.76:5060;received=x.x.158.76;rport=5060;branch=z9hG4bK-5a850258-2244-b548b57
>> Via: SIP/2.0/UDP x.x.158.68:5060;branch=z9hG4bK-9579e-247e414d-51cc153d-7fabe8816328
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, NOTIFY, MESSAGE, SUBSCRIBE
>> Supported: replaces, eventlist
>> User-Agent: Bria 3 release 3.5.5 stamp 71243
>> Content-Type: application/sdp
>> Content-Length: 275
>> Contact: <sip:ngcp-lb at x.x.153.35:5060;ngcpct=7369703a3132372e302e302e313a353038303b707278726f7574653d31> <sip:ngcp-lb at x.x.153.35:5060;ngcpct=7369703a3132372e302e302e313a353038303b707278726f7574653d31>
>> Message Body
>> Session Description Protocol
>> Session Description Protocol Version (v): 0
>> Owner/Creator, Session Id (o): - 0 3 IN IP4 x.x.153.35
>> Session Name (s): Bria 3 release 3.5.5 stamp 71243
>> Connection Information (c): IN IP4 x.x.153.35
>> Time Description, active time (t): 0 0
>> Media Description, name and address (m): audio 30362 RTP/AVP 18 101
>> Media Attribute (a): rtpmap:18 G729/8000
>> Media Attribute (a): fmtp:18 annexb=yes
>> Media Attribute (a): rtpmap:101 telephone-event/8000
>> Media Attribute (a): fmtp:101 0-15
>> Media Attribute (a): direction:both
>> Media Attribute (a): sendrecv
>> Media Attribute (a): rtcp:30363
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
>> https://lists.sipwise.com/listinfo/spce-user <https://lists.sipwise.com/listinfo/spce-user>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20180228/bc680f5c/attachment-0001.html>
More information about the Spce-user
mailing list