[Home]

Summary:ASTERISK-16449: [patch] Video RTP type in response SDP not matching the one in INVITE
Reporter:Sergio Garcia (sgarcia)Labels:
Date Opened:2010-07-28 04:24:56Date Closed:2011-12-12 15:57:51.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Video
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) video.patch
Description:When creating the SDP for answering a SIP call only audio types are matched against the incoming INVITE SDP. As a result the default rtp codecs type for video are used instead.

Even if that is tenchically correct, that causes softphones like Port SIP or Pangolin not to display incomming video as expects the same rtp codec type for both rtp video streams.

For audio it is already done, so the it will be much more coherent to do it in video also. The ptch is quite simple:


<inline patch removed by lmadsen -- please upload as a file>
Comments:By: Leif Madsen (lmadsen) 2010-07-28 13:35:15

I have removed your inline patch from the description. In order to have your code evaluated you must sign the license agreement and then upload your patch to the issue. Thanks!
By: Sergio Garcia (sgarcia) 2010-07-28 16:15:30

Done. I forgot to upload it at the first time. License agreement already aproved.
By: Leif Madsen (lmadsen) 2010-07-29 10:53:30

Thanks!
By: Leif Madsen (lmadsen) 2010-07-29 15:06:06

This issue needs to be posted to reviewboard, and once a Ship It has been obtained it can be committed. Thanks!
By: Olle Johansson (oej) 2010-07-29 15:45:12

According to the RFC we should only answer with one or multiple codecs that exist in the offer. I don't really understand if we break this here, without seeing any SIP debug output.

I would like to see SIP debug output where we do wrong, and after your patch, to be able to make a comment on what you're doing here. Thank you.
By: Sergio Garcia (sgarcia) 2010-07-30 03:38:51

Hi Olle,

We are not adding new codecs, the patchs is just matching the RTP type number of the codecs we send in the SDP response with the ones offered in the INVITE.

Without the patch the call flow is (removed ip addresses)

INVITE sip:300@XX.XX.XX.XX SIP/2.0
Via: SIP/2.0/UDP 192.168.1.33:5288;branch=z9hG4bK-d8754z-290acf6d1a2ac71e-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:200@192.168.1.33:5288>
To: <sip:300@XX.XX.XX.XX>
From: "200"<sip:200@XX.XX.XX.XX>;tag=d2626f7d
Call-ID: ZWU1ZmM2YmZkYzk1MWQ0Yjg4NTM5MjEyYjg5MTFjNzI.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, UBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: Pangolin v5.3, Build 11292009
Content-Length: 471

v=0
o=- 5973438 5973438 IN IP4 192.168.1.33
s=http://www.portsip.com
c=IN IP4 192.168.1.33
t=0 0
m=audio 21352 RTP/AVP 0 8 18 3 98 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=fmtp:101 0-15
m=video 40694 RTP/AVP 125
a=fmtp:125 profile-level-id=42801e; packetization-mode=1
a=rtpmap:125 H264/90000

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.33:5288;branch=z9hG4bK-d8754z-290acf6d1a2ac71e-1---d8754z-;received=79.154.129.162;rport=5288
From: "200"<sip:200@XX.XX.XX.XX>;tag=d2626f7d
To: <sip:300@XX.XX.XX.XX>;tag=as7262f783
Call-ID: ZWU1ZmM2YmZkYzk1MWQ0Yjg4NTM5MjEyYjg5MTFjNzI.
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:300@XX.XX.XX.XX>
Content-Type: application/sdp
Content-Length: 340

v=0
o=root 4708 4708 IN IP4 XX.XX.XX.XX
s=session
c=IN IP4 XX.XX.XX.XX
b=CT:512
t=0 0
m=audio 15936 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 13282 RTP/AVP 99
a=rtpmap:99 H264/90000
a=sendrecv


Note that in the first SDP h264 has an RTP codec type of 126 and in the response SDP 99 (the default asterisk one).

The patch changes that, using the offered number (126) in the reply instead.
m=video 13282 RTP/AVP 125
a=rtpmap:125 H264/90000
a=sendrecv


Best regards
Sergio
By: Matt Jordan (mjordan) 2011-12-12 15:57:36.827-0600

The handling of assigning codecs to the SDP changed significantly since this patch was written.  In trunk (12/12/11), what this patch intended to do already occurs - the format type identifier is preserved between the initial INVITE and subsequent responses from Asterisk.  As this is not mandated by the RFC, this functionality would only have been added to trunk, and not patched to 1.8 and 10.  As such, since trunk already has this functionality, there isn't any additional work needed.

Please feel free to test with trunk and see if the SIP clients mentioned in your issue work with it.