[Home]

Summary:ASTERISK-02197: If videosupport=yes, SDP response on "voice only" calls include TWO media streams in SDP (one for voice and one for video)
Reporter:ltropiano (ltropiano)Labels:
Date Opened:2004-08-06 15:49:51Date Closed:2008-01-15 15:05:17.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sdp-video.pcap
Description:if sip.conf has videosupport=yes, and an audio-only call generates an OFFER with a single media stream in the SDP packet, Asterisk incorrectly responds back with an SDP answer with two media streams (audio and *video*).  

RFC 3264  An Offer/Answer Model Session Description Protocol   June 2002  

Beyond that clarification, the semantics of an offered multicast   stream are exactly as described in RFC 2327 [1].

6 Generating the Answer  

The answer to an offered session description is based on the offered   session description.  If the answer is different from the offer in   any way (different IP addresses, ports, etc.), the origin line MUST   be different in the answer, since the answer is generated by a   different entity.  In that case, the version number in the "o=" line   of the answer is unrelated to the version number in the o line of the   offer.  

For each "m=" line in the offer, there MUST be a corresponding "m="   line in the answer.  The answer MUST contain exactly the same number    of "m=" lines as the offer.  This allows for streams to be matched up   based on their order.  This implies that if the offer contained zero   "m=" lines, the answer MUST contain zero "m=" lines.
Comments:By: Mark Spencer (markster) 2004-08-06 17:06:04

You'll need to find me on IRC so I can login and try to figure out why that's happening.  Also please confirm you really are running latest CVS head.  Thanks!
By: ltropiano (ltropiano) 2004-08-06 17:20:46

localhost*CLI> show version
Asterisk CVS-HEAD-07/02/04-20:34:08 built by root@localhost.localdomain on a i686 running Linux


Not super current, but...

Attached is an "Ethereal" trace.  Look at packet 4 and packet 6.  The INVITE had one (m=) and the OK had two.
By: Mark Spencer (markster) 2004-08-06 17:48:51

I can't duplicate this problem on this system so I'm going to have to try to figure out what is special about yours.  Please update to latest CVS and find me on IRC so I can login if the problem has not already been solved by updating to altest CVS *head*.  Thanks!
By: Mark Spencer (markster) 2004-08-07 18:53:15

I'm still unable to duplicate this bug so I'm going to consider this fixed unless you can duplicate it with latest CVS, in which case feel free to reopen it.
By: ltropiano (ltropiano) 2004-08-07 20:17:17

Asterisk CVS-HEAD-08/06/04-22:39:33 built by root@localhost.localdomain on a i686 running Linux

Yes, I can reproduce it.

Here's the section from sip.conf:

[general]
port = 5060                     ; Port to bind to
bindaddr = 0.0.0.0              ; Address to bind SIP channel to
context = default               ; Default context for incoming calls
videosupport=yes                ; Turn on support for SIP video

[2024]
type=friend                    
username=2024
host=dynamic
qualify=no
canreinvite=no

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

Here's the extensions.conf section:

exten => 999,1,Answer
exten => 999,2,Playback(demo-congrats)  ; Play a congratulatory message
exten => 999,3 Wait(4) ; Wait for the test client to send a bye.
exten => 999,4,Hangup


NOTE: this is used in our development with automated scripts, hence the weirdness in the extension.conf... :)
By: ltropiano (ltropiano) 2004-08-07 20:18:08

The test case is 2024 is a Cisco 7960... it calls 999.  The Attached file is the exact trace from that on port 5060 only.
By: Mark Spencer (markster) 2004-08-07 22:05:15

Then find me on IRC so i can login and look.
By: ltropiano (ltropiano) 2004-08-07 22:12:19

I've msg'd on irc ... machine is in our corporate offices, behind our firewall.  Is there anything else I can offer you as far as debugging info?
By: ltropiano (ltropiano) 2004-08-07 23:00:11

Here's the sip debug of a call with an X-lite client to 999 on the * server...

Note the lines:
   m=video 10470 RTP/AVP 34
   a=rtpmap:34 H263/90000


Sip read:
INVITE sip:999@test1.rocksteady.com SIP/2.0
Via: SIP/2.0/UDP 10.50.34.1:5060;branch=z9hG4bK3a7eadfd46bbec16ec26e61036e48bc0,SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bK0B27E8688EE045C9B7D70C057AEFFE64
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>
Contact: <sip:3024@10.50.34.16:5060>
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57210 INVITE
Max-Forwards: 69
User-Agent: X-PRO build 1082
Content-Type: application/sdp
Record-Route: <sip:10.50.34.1:5060;transport=udp>
Content-Length: 239

v=0
o=3024 87390480 87390480 IN IP4 10.50.34.16
s=X-PRO
c=IN IP4 10.50.34.16
t=0 0
m=audio 8000 RTP/AVP 0 3 98 101
a=rtpmap:0 pcmu/8000
a=rtpmap:3 gsm/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

12 headers, 11 lines
Using latest request as basis request
Sending to 10.50.34.1 : 5060 (non-NAT)
Found RTP audio format 0
Found RTP audio format 3
Found RTP audio format 98
Found RTP audio format 101
Peer audio RTP is at port 10.50.34.16:8000
Found description format pcmu
Found description format gsm
Found description format iLBC
Found description format telephone-event
Capabilities: us - 0x8000e(GSM|ULAW|ALAW|H263), peer - audio=0x406(GSM|ULAW|ILBC)/video=0x0(EMPTY), combined - 0x6(GSM|ULAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x1(G723), combined - 0x1(G723)
Found user '3024'
Looking for 999 in default
list_route: hop: <sip:10.50.34.1:5060;transport=udp>
list_route: hop: <sip:3024@10.50.34.16:5060>
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.50.34.1:5060;branch=z9hG4bK3a7eadfd46bbec16ec26e61036e48bc0,SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK0B27E8688EE045C9B7D70C057AEFFE64
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>;tag=as1353858c
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57210 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Length: 0


to 10.50.34.1:5060
   -- Executing Answer("SIP/3024-4b8b", "") in new stack
We're at 10.1.200.1 port 17018
Video is at 10.1.200.1 port 10470
Answering with capability 0x2(GSM)
Answering with capability 0x4(ULAW)
Answering with capability 0x8(ALAW)
Answering with capability 0x80000(H263)
Answering with non-codec capability 0x1(G723)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.34.1:5060;branch=z9hG4bK3a7eadfd46bbec16ec26e61036e48bc0,SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK0B27E8688EE045C9B7D70C057AEFFE64
Record-Route: <sip:10.50.34.1:5060;transport=udp>
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>;tag=as1353858c
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57210 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Type: application/sdp
Content-Length: 307

v=0
o=root 3001 3001 IN IP4 10.1.200.1
s=session
c=IN IP4 10.1.200.1
t=0 0
m=audio 17018 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
m=video 10470 RTP/AVP 34
a=rtpmap:34 H263/90000

to 10.50.34.1:5060
   -- Executing Playback("SIP/3024-4b8b", "demo-congrats") in new stack
   -- Playing 'demo-congrats' (language 'en')
localhost*CLI>

Sip read:
ACK sip:10.50.34.1:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 66.143.172.151:5060;branch=z9hG4bK5a81259ea19efff7bdf6376421bab873,SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bKFDEC2E7C1A4645119C625AB221DBD8F6
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>;tag=as1353858c
Contact: <sip:3024@10.50.34.16:5060>
Route: <sip:999@10.1.200.1>
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57210 ACK
Max-Forwards: 69
Record-Route: <sip:66.143.172.151:5060;transport=udp>
Content-Length: 0


11 headers, 0 lines
localhost*CLI>

Sip read:
BYE sip:10.50.34.1:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 66.143.172.151:5060;branch=z9hG4bK211d26b9cfe5284e633fac99bfb6d702,SIP/2.0/UDP 10.50.34.16:5060;rport;branch=z9hG4bKC9AA120FD4A94A708043B3F98B895C3F
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>;tag=as1353858c
Contact: <sip:3024@10.50.34.16:5060>
Route: <sip:999@10.1.200.1>
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57211 BYE
User-Agent: X-PRO build 1082
Max-Forwards: 70
Record-Route: <sip:66.143.172.151:5060;transport=udp>
Content-Length: 0


12 headers, 0 lines
Sending to 66.143.172.151 : 5060 (non-NAT)
Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 66.143.172.151:5060;branch=z9hG4bK211d26b9cfe5284e633fac99bfb6d702,SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bKC9AA120FD4A94A708043B3F98B895C3F
Record-Route: <sip:66.143.172.151:5060;transport=udp>
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>;tag=as1353858c
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57211 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Length: 0
By: Mark Spencer (markster) 2004-08-11 16:35:35

Maybe post your sip.conf friend entry as well as the general section?

Ideally I really need to get access to your system to work on this bug as I cannot duplicate it.

I'll give this one more shot here, but if I cannot duplicate the problem with your configuration and you are unable to provide access to the machine that it occurs on, I think this will just have to be closed out as "cannot duplicate".
By: Olle Johansson (oej) 2004-08-12 16:24:41

Similar to bug ASTERISK-1387
By: ltropiano (ltropiano) 2004-08-12 16:29:56

Indeed, same thing.  But I don't believe it's fixed in -HEAD.  Working on getting Mark Spencer access to a system.  I verified last night with CVS-HEAD (current from last night);

make install
make samples
edit sip.conf, turn on videosupport=yes, add simple friend entry and called "8500" ...

The 200 OK had the "m=" video RTP response.
By: Olle Johansson (oej) 2004-08-14 04:27:20

I can not duplicate this on CVS head with my X-lite.

Lenny, do you have an old version of the SIP channel for some reason?

Please delete chan_sip.c, do a "make update" and recompile. "cvs show status channels/chan_sip.c" should show version 1.468.

If you have 1.468 running, please make sure that Mark get's access anyhow, if at all possible.

I would also like to see the full SIP debug with both calls - from X-lite to asterisk *and* the call from Asterisk to the Cisco. Is it possible to capture that and add as a text file to this bug report? In the debug below, I only see the conversation between X-lite and Asterisk.
By: ltropiano (ltropiano) 2004-08-14 08:55:22

Ok, first thing first... this is a brand new checkout of asterisk... here's the cvs status.

[root@standby-pbx channels]# cvs status chan_sip.c
===================================================================
File: chan_sip.c        Status: Up-to-date

  Working revision:    1.468
  Repository revision: 1.468   /usr/cvsroot/asterisk/channels/chan_sip.c,v
  Sticky Tag:          (none)
  Sticky Date:         (none)
  Sticky Options:      (none)

[root@standby-pbx channels]#


Second thing, the call RTP channels is always from UA<->asterisk (UA can be anything, from X-lite, Polycom, Cisco, etc..).  I just call and get an audio stream back from asterisk (ie. just called 8500 in the above "sip debug" example, which was the voice mail extension from the make samples).  

If you see (repeated here for clarity):

We're at 10.1.200.1 port 17018
Video is at 10.1.200.1 port 10470
Answering with capability 0x2(GSM)
Answering with capability 0x4(ULAW)
Answering with capability 0x8(ALAW)
Answering with capability 0x80000(H263)
Answering with non-codec capability 0x1(G723)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.34.1:5060;branch=z9hG4bK3a7eadfd46bbec16ec26e61036e48bc0,SIP/2.0/UDP 10.50.34.16:5060;branch=z9hG4bK0B27E8688EE045C9B7D70C057AEFFE64
Record-Route: <sip:10.50.34.1:5060;transport=udp>
From: "Lenny Tropiano" <sip:3024@test1.rocksteady.com>;tag=355367485
To: <sip:999@test1.rocksteady.com>;tag=as1353858c
Call-ID: 1E0B3ABB-6256-4E29-98DF-3BE2BB169F8A@10.50.34.16
CSeq: 57210 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:999@10.1.200.1>
Content-Type: application/sdp
Content-Length: 307

v=0
o=root 3001 3001 IN IP4 10.1.200.1
s=session
c=IN IP4 10.1.200.1
t=0 0
m=audio 17018 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
m=video 10470 RTP/AVP 34
a=rtpmap:34 H263/90000


It responds:

 Answering with capability 0x80000(H263)

And then puts:
 m=video 10470 RTP/AVP 34
 a=rtpmap:34 H263/90000

What I think is wrong is that, indeed with videosupport=yes, the capability of asterisk does support that codec... but it shouldn't respond with that capability and media stream "m=" when the request TO asterisk was audio only with one audio only media stream.

Clearly the code in question is in the "for loop" at line 3405-3424 in chan_sip.c.

The for loop checks videosupport, and if it's on (no matter what) it iterates through the entire list of codecs up to AST_FORMAT_MAX_VIDEO...

I don't know the exact fix without delving further...
By: ltropiano (ltropiano) 2004-08-14 09:02:18

OK, I delved further... how about this for a fix??   Mark?

line: 3406 of chan_sip.c from:

       for (x = 1; x <= ((videosupport && p->vrtp) ? AST_FORMAT_MAX_VIDEO : AST_FORMAT_MAX_AUDIO); x <<= 1) {

to:

       for (x = 1; x <= (videosupport ? AST_FORMAT_MAX_VIDEO : AST_FORMAT_MAX_AUDIO); x <<= 1) {
By: Olle Johansson (oej) 2004-08-14 10:08:38

Lenny, sorry, I confused your report with another (asking for the other call leg).

The strange thing is that we can't repeat this. Maybe you could mail me a complete config of yours, since I believe I'm missing something significant. Then I'll load Asterisk with your config and see if I can repeat this. It would be much easier testing  your fix if I can repeat the problem :-)
By: ltropiano (ltropiano) 2004-08-14 10:14:11

OK, I'd be happy to send you all the configs, but easier than that...

# make samples
# vi /etc/asterisk/sip.conf

Uncomment:
videosupport=yes ; Turn on support for SIP video

Add:
[2024]
type=friend
username=2024
host=dynamic
qualify=no
canreinvite=no

Restart or reload asterisk...

Register with any voice-only UA as 2024...

CLI> sip debug

Now call 8500.

Look at the debug output for the "200 OK" to the INVITE.
By: ltropiano (ltropiano) 2004-08-16 21:59:59

My mistake in the patch... currently the line 3406 in chan_sip.c says:

for (x = 1; x <= (videosupport ? AST_FORMAT_MAX_VIDEO : AST_FORMAT_MAX_AUDIO); x <<= 1) {

and I'm proposing to changing it TO:

for (x = 1; x <= ((videosupport && p->vrtp) ? AST_FORMAT_MAX_VIDEO : AST_FORMAT_MAX_AUDIO); x <<= 1) {
By: Mark Spencer (markster) 2004-08-16 22:21:20

Fixed in CVS
By: ltropiano (ltropiano) 2004-08-17 15:58:36

I hate to do this; but apparently my fix isn't as sorcerer as I originally thought.  Now I can reproduce this and explain a little better, after delving into the code this morning.

So, basically:

1. static int global_capability = AST_FORMAT_ULAW | AST_FORMAT_ALAW | AST_FORMAT_GSM | AST_FORMAT_H263;

  Includes the H263 codec.  That in itself isn't too bad, but induces the problem.

2. sip.conf by default has all no "disallow" or "allow" statements.  And if videosupport is on, the "user" no matter what UA gets the global_capability.

3. Say the user is a Cisco 7960 phone, no video support capability whatsoever.    But by default it does an INVITE with it's codecs (the find_user) routine then overwrites the p->capability = global_capability...

4. The INVITE has a set of codecs, and just a single audio media stream (m=).

5. The 200 OK from the INVITE has some additional codecs (not violating the spec), but incorrectly the m= (media stream) for a VIDEO stream (this is because the global_capability is set as such).  This violates the SDP spec.

6. Yes, I can turn this off by disallow=all, allow=ulaw, alaw, g729... statements, but it seems like the device should be the one to dictate which codecs it uses.

So my fix can come out, it doesn't solve anything... Ultimately some more thought needs to go into it.
By: Mark Spencer (markster) 2004-08-17 22:29:31

Okay I give up.  I added a "novideo" field to the structure to track whether video was invited or not.

SIP is such total crap.
By: Digium Subversion (svnbot) 2008-01-15 15:05:17.000-0600

Repository: asterisk
Revision: 3619

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3619 | markster | 2008-01-15 15:05:16 -0600 (Tue, 15 Jan 2008) | 2 lines

Add another field to track whether video was invited or not (bug ASTERISK-2197)

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

http://svn.digium.com/view/asterisk?view=rev&revision=3619