[OpenSIPS-Devel] [ opensips-Bugs-2048110 ] SDP payload truncated

SourceForge.net noreply at sourceforge.net
Wed Aug 13 12:57:17 CEST 2008


Bugs item #2048110, was opened at 2008-08-12 16:25
Message generated for change (Comment added) made by mstubbs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2048110&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Stubbs (mstubbs)
Assigned to: Nobody/Anonymous (nobody)
Summary: SDP payload truncated

Initial Comment:
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 at 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 at 5.5.5.5>;tag=16C8E3C8-7CD.
To: <sip:09904441111111111 at pstn.gateway.com>.
Date: Tue, 12 Aug 2008 14:53:38 gmt.
Call-ID: 47EE9B89-67B511DD-9F33EFB9-710EBE4B at 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 at 5.5.5.5>;party=calling;screen=yes;privacy=off.
Timestamp: 1218552818.
Contact: <sip:22222222222 at 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 at 5.5.5.5>;tag=16C8E3C8-7CD.
To: <sip:09904441111111111 at pstn.gateway.com>.
Call-ID: 47EE9B89-67B511DD-9F33EFB9-710EBE4B at 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 at 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 at 5.5.5.5>;tag=16C8E3C8-7CD.
To: <sip:09904441111111111 at pstn.gateway.com>.
Date: Tue, 12 Aug 2008 14:53:38 gmt.
Call-ID: 47EE9B89-67B511DD-9F33EFB9-710EBE4B at 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 at 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
#

----------------------------------------------------------------------

>Comment By: Mark Stubbs (mstubbs)
Date: 2008-08-13 11:57

Message:
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!)

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2008-08-12 16:32

Message:
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2048110&group_id=232389



More information about the Devel mailing list