#4 SDP payload truncated

closed
nobody
None
5
2008-08-13
2008-08-12
Mark Stubbs
No

Have been testing a new OpenSIPS (1.4.0-notls on a 32-bit CentoOS 5 box) configured to do simple unconditional call forwarding (by just rewriting the R-URI). Although the forwarding works OK, the audio quality is poor. After debugging a SIP trace (see below) I noticed that the SDP payload is being truncated (though the Content-Length is unchanged) so RTP ends up picking a low-bandwith codec. Here's an extract from the trace:

INITIAL INVITE
#
U 2008/08/12 10:53:38.956488 2.2.2.2:5060 -> 1.1.1.1:5060
INVITE sip:11111111111@my.opensips.com SIP/2.0.
Record-Route: <sip:2.2.2.2;lr=on;ftag=16C8E3C8-7CD>.
Record-Route: <sip:3.3.3.3;lr=on;ftag=16C8E3C8-7CD>.
Record-Route: <sip:4.4.4.4;ftag=16C8E3C8-7CD;lr=on>.
Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK97cd.bcc064f3.0.
Via: SIP/2.0/UDP 3.3.3.3;branch=z9hG4bK97cd.3f7957f3.0.
Via: SIP/2.0/UDP 4.4.4.4;branch=z9hG4bK97cd.6fafad46.0.
Via: SIP/2.0/UDP 5.5.5.5:5060;branch=z9hG4bK1ADE1D825AA.
From: <sip:22222222222@5.5.5.5>;tag=16C8E3C8-7CD.
To: <sip:09904441111111111@pstn.gateway.com>.
Date: Tue, 12 Aug 2008 14:53:38 gmt.
Call-ID: 47EE9B89-67B511DD-9F33EFB9-710EBE4B@5.5.5.5.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
CSeq: 101 INVITE.
Max-Forwards: 12.
Remote-Party-ID: <sip:22222222222@5.5.5.5>;party=calling;screen=yes;privacy=off.
Timestamp: 1218552818.
Contact: <sip:22222222222@5.5.5.5:5060>.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Length: 404.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 7389 8677 IN IP4 5.5.5.5.
s=SIP Call.
c=IN IP4 5.5.5.5.
t=0 0.
m=audio 16510 RTP/AVP 4 18 3 2 8 0 101.
c=IN IP4 5.5.5.5.
a=rtpmap:4 G723/8000.
a=fmtp:4 annexa=no.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=yes.
a=rtpmap:3 GSM/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000

#
U 2008/08/12 10:53:38.957259 1.1.1.1:5060 -> 2.2.2.2:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK97cd.bcc064f3.0.
Via: SIP/2.0/UDP 3.3.3.3;branch=z9hG4bK97cd.3f7957f3.0.
Via: SIP/2.0/UDP 4.4.4.4;branch=z9hG4bK97cd.6fafad46.0.
Via: SIP/2.0/UDP 5.5.5.5:5060;branch=z9hG4bK1ADE1D825AA.
From: <sip:22222222222@5.5.5.5>;tag=16C8E3C8-7CD.
To: <sip:09904441111111111@pstn.gateway.com>.
Call-ID: 47EE9B89-67B511DD-9F33EFB9-710EBE4B@5.5.5.5.
CSeq: 101 INVITE.
Server: OpenSIPS (1.4.0-notls (i386/linux)).
Content-Length: 0.
.
# Modified INVITE (SDP truncated)
U 2008/08/12 10:53:38.959486 1.1.1.1:5060 -> 4.4.4.4:5060
INVITE sip:3333333333@pstn.gateway.com SIP/2.0.
Record-Route: <sip:6.6.6.6;ftag=16C8E3C8-7CD;lr=on>.
Record-Route: <sip:2.2.2.2;lr=on;ftag=16C8E3C8-7CD>.
Record-Route: <sip:3.3.3.3;lr=on;ftag=16C8E3C8-7CD>.
Record-Route: <sip:4.4.4.4;ftag=16C8E3C8-7CD;lr=on>.
Via: SIP/2.0/UDP 6.6.6.6;branch=z9hG4bK97cd.69b74485.0.
Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK97cd.bcc064f3.0.
Via: SIP/2.0/UDP 3.3.3.3;branch=z9hG4bK97cd.3f7957f3.0.
Via: SIP/2.0/UDP 4.4.4.4;branch=z9hG4bK97cd.6fafad46.0.
Via: SIP/2.0/UDP 5.5.5.5:5060;branch=z9hG4bK1ADE1D825AA.
From: <sip:22222222222@5.5.5.5>;tag=16C8E3C8-7CD.
To: <sip:09904441111111111@pstn.gateway.com>.
Date: Tue, 12 Aug 2008 14:53:38 gmt.
Call-ID: 47EE9B89-67B511DD-9F33EFB9-710EBE4B@5.5.5.5.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
CSeq: 101 INVITE.
Max-Forwards: 11.
Timestamp: 1218552818.
Contact: <sip:22222222222@5.5.5.5:5060>.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Length: 404.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 7389 8677 IN IP4 5.5.5.5.
s=SIP Call.
c=IN IP4 5.5.5.5.
t=0 0.
m=audio 16510 RTP/AVP 4 18 3 2 8 0 101.
c=IN IP4 5.5.5.5.
a=rtpmap:4 G723/8000.
a=fmtp:4 annexa=no.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=yes.
a=rtpmap:3 GSM/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:8 P <== Data truncated here
#

Discussion

  • Ovidiu Sas

    Ovidiu Sas - 2008-08-12

    Logged In: YES
    user_id=1395524
    Originator: NO

    The SDP is not truncated, it is the UDP packet that is fragmented. Do a full pcap capture and you will see the second UDP packet.
    Because you have to many headers, your SIP message doesn't fit anymore inside a single UDP packet and therefore it is fragmented.

    Regards,
    Ovidiu Sas

     
  • Mark Stubbs

    Mark Stubbs - 2008-08-13

    Logged In: YES
    user_id=2178320
    Originator: YES

    Yup - can see it now. Sorry for the dumb report (I'm a bit of a newbie to all this!)

     
  • Mark Stubbs

    Mark Stubbs - 2008-08-13
    • status: open --> closed
     

Log in to post a comment.