[Home]

Summary:ASTERISK-13112: SDP replies incorrect - 'a=inactive' - replied to with 'a=sendrecv'
Reporter:TOC Jason (toc)Labels:
Date Opened:2008-11-24 05:15:43.000-0600Date Closed:2009-06-15 16:29:28
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug13958-trunk164941-3.diff
Description:When asterisk is sent a packet from Microsoft OCS Mediation Server, where the call is being placed on hold, Asterisk sends an incorrect response.

Mediation server is 192.168.1.208

Asterisk is 192.168.1.250 (on 5061).
OpenSIPS is intercepting to resolve the bug on 192.168.1.250 (on 5060)

The packet sent from OCS is below (intercepted using OpenSIPS):
[  Method INVITE from 192.168.1.208:1276 (2)  ]
INVITE sip:01234567@192.168.1.250:5061 SIP/2.0
FROM: <sip:First.Last@domain.com>;epid=A4325290A1;tag=f7768ee4ad
TO: <sip:01234567@192.168.1.250;user=phone>;tag=as79279f7b
CSEQ: 69 INVITE
CALL-ID: 1ae1e5ef-f96f-482c-9c44-da92c9094ecc
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.1.208:1276;branch=z9hG4bK1d297960
CONTACT: <sip:domain.com.au:5060;transport=Tcp;maddr=192.168.1.208;ms-opaque=2cea147ecbefbb7f>
CONTENT-LENGTH: 268
SUPPORTED: 100rel
USER-AGENT: RTCC/3.0.0.0 MediationServer
CONTENT-TYPE: application/sdp; charset=utf-8

v=0
o=- 0 0 IN IP4 192.168.1.208
s=session
c=IN IP4 192.168.1.208
b=CT:1000
t=0 0
m=audio 60806 RTP/AVP 0 101
c=IN IP4 192.168.1.208
a=rtcp:60807
a=inactive
a=label:Audio
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
[  End of Request (2)  ]


Response from Asterisk:


[  Reply 200 (OK) from 192.168.1.250:5061 concerning INVITE  ]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.250;branch=z9hG4bK3795.6ca29175.0;i=2;received=192.168.1.250
Via: SIP/2.0/TCP 192.168.1.208:1276;branch=z9hG4bK1d297960
From: <sip:First.Last@domain.com.au>;epid=A4325290A1;tag=f7768ee4ad
To: <sip:01234567@192.168.1.250;user=phone>;tag=as79279f7b
Call-ID: 1ae1e5ef-f96f-482c-9c44-da92c9094ecc
CSeq: 69 INVITE
User-Agent: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:01234567@192.168.1.250:5061>
Content-Type: application/sdp
Content-Length: 261

v=0
o=root 295744575 295744576 IN IP4 192.168.1.250
s=Asterisk PBX 1.6.0
c=IN IP4 192.168.1.250
t=0 0
m=audio 19848 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
[  End of Reply  ]

The asterisk packet contains an incorrect a=sendrecv, it should be a=inactive as OCS has requested the call to be placed on hold.

The hold works when modifying the packet from a=sendrecv to a=inactive using OpenSIPS.
Comments:By: Leif Madsen (lmadsen) 2008-11-24 09:14:32.000-0600

Assigned to mnicholson for a quick review to determine if he can take this issue on. Sorry for using the wrong method of assigning at first. Switching this back to new for now, then we'll go to acknowledged once mnicholson determines what to do with this issue.

Please reassign if necessary.

Thanks!
By: Matthew Nicholson (mnicholson) 2008-12-09 16:21:13.000-0600

Try the patch I just posted and let me know if it fixes the issue please.
By: Matthew Nicholson (mnicholson) 2008-12-09 16:45:13.000-0600

Actually that patch should not really change anything.  Looking at the code, the scenario you are describing should work properly.  Can you test with history recording enabled and see if there is a hold event recorded in the history?

From the CLI run:

sip set history on

To enable history and then:

sip show history

To view the history.
By: TOC Jason (toc) 2008-12-10 02:14:50.000-0600

Ok - reverted to the asterisk + OCS mediation server (no patch applied):

More feedback pending the patch being applied.

 * SIP Call
1. Rx              INVITE / 232 INVITE / sip:<external number>@192.168.1.250;user=phone
2. NewChan         Channel SIP/network.domain.com.au-08bc0b48 - fr
3. TxResp          SIP/2.0 / 232 INVITE - 100 Trying
4. TxResp          SIP/2.0 / 232 INVITE - 180 Ringing
5. TxRespRel       SIP/2.0 / 232 INVITE - 200 OK
6. Rx              ACK / 232 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
7. Rx              INVITE / 233 INVITE / sip:<external number>@192.168.1.250:5060;transpo
8. ReInv           Re-invite received
9. TxResp          SIP/2.0 / 233 INVITE - 100 Trying
10. TxRespRel       SIP/2.0 / 233 INVITE - 200 OK
11. Rx              ACK / 233 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP


# pressed hold

test*CLI>
 * SIP Call
1. Rx              INVITE / 232 INVITE / sip:<external number>@192.168.1.250;user=phone
2. NewChan         Channel SIP/network.domain.com.au-08bc0b48 - fr
3. TxResp          SIP/2.0 / 232 INVITE - 100 Trying
4. TxResp          SIP/2.0 / 232 INVITE - 180 Ringing
5. TxRespRel       SIP/2.0 / 232 INVITE - 200 OK
6. Rx              ACK / 232 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
7. Rx              INVITE / 233 INVITE / sip:<external number>@192.168.1.250:5060;transpo
8. ReInv           Re-invite received
9. TxResp          SIP/2.0 / 233 INVITE - 100 Trying
10. TxRespRel       SIP/2.0 / 233 INVITE - 200 OK
11. Rx              ACK / 233 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
12. Rx              INVITE / 234 INVITE / sip:<external number>@192.168.1.250:5060;transpo
13. ReInv           Re-invite received
14. TxResp          SIP/2.0 / 234 INVITE - 100 Trying
15. TxRespRel       SIP/2.0 / 234 INVITE - 200 OK
16. Rx              ACK / 234 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP


And here's another, doing exact the same, with SIP debug (note a=inactive from OCS, replied to with a=sendrecv by Asterisk):

<--- SIP read from TCP://192.168.1.208:1335 --->
INVITE sip:<external number>@192.168.1.250:5060;transport=TCP SIP/2.0
FROM: <sip:First.Last@network.domain.com.au>;epid=A4325290A1;tag=16f16e814
TO: <sip:<external number>@192.168.1.250;user=phone>;tag=as1d515069
CSEQ: 236 INVITE
CALL-ID: 7ca84582-7c97-4706-a3da-70068a647fd3
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.1.208:1335;branch=z9hG4bKd2f9eb80
CONTACT: <sip:Mediation.network.domain.com.au:5060;transport=Tcp;maddr=192.168.1.208;ms-opaque=2cea147ecbefbb7f>
CONTENT-LENGTH: 268
SUPPORTED: 100rel
USER-AGENT: RTCC/3.0.0.0 MediationServer
CONTENT-TYPE: application/sdp; charset=utf-8

v=0
o=- 0 0 IN IP4 192.168.1.208
s=session
c=IN IP4 192.168.1.208
b=CT:1000
t=0 0
m=audio 60472 RTP/AVP 0 101
c=IN IP4 192.168.1.208
a=rtcp:60473
a=inactive
a=label:Audio
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
0
a=rtpmap:8 PCMA/8000
a=ptime:20

<------------->
--- (12 headers 18 lines) ---
Sending to 192.168.1.208 : 1335 (no NAT)
test*CLI>
<--- Transmitting (no NAT) to 192.168.1.208:1335 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.1.208:1335;branch=z9hG4bKd2f9eb80;received=192.168.1.208
From: <sip:First.Last@network.domain.com.au>;epid=A4325290A1;tag=16f16e814
To: <sip:<external number>@192.168.1.250;user=phone>;tag=as1d515069
Call-ID: 7ca84582-7c97-4706-a3da-70068a647fd3
CSeq: 236 INVITE
User-Agent: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:<external number>@192.168.1.250:5060;transport=TCP>
Content-Length: 0


<------------>
Audio is at 192.168.1.250 port 12568
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
test*CLI>
<--- Reliably Transmitting (no NAT) to 192.168.1.208:1335 --->
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.208:1335;branch=z9hG4bKd2f9eb80;received=192.168.1.208
From: <sip:First.last@network.domain.com.au>;epid=A4325290A1;tag=16f16e814
To: <sip:<external number>@192.168.1.250;user=phone>;tag=as1d515069
Call-ID: 7ca84582-7c97-4706-a3da-70068a647fd3
CSeq: 236 INVITE
User-Agent: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:<external number>@192.168.1.250:5060;transport=TCP>
Content-Type: application/sdp
Content-Length: 259

v=0
o=root 83368207 83368207 IN IP4 192.168.1.250
s=Asterisk PBX 1.6.0
c=IN IP4 192.168.1.250
t=0 0
m=audio 12568 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
By: TOC Jason (toc) 2008-12-10 02:22:02.000-0600

Patch applied and installed (did not work)- asterisk 1.6.0:

 * SIP Call
1. Rx              INVITE / 234 INVITE / sip:<external number>@192.168.1.250;user=phone
2. NewChan         Channel SIP/network.domain.com.au-0950ae10 - fr
3. TxResp          SIP/2.0 / 234 INVITE - 100 Trying
4. TxResp          SIP/2.0 / 234 INVITE - 180 Ringing
5. TxRespRel       SIP/2.0 / 234 INVITE - 200 OK
6. Rx              ACK / 234 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
7. Rx              INVITE / 235 INVITE / sip:<external number>@192.168.1.250:5060;transpo
8. ReInv           Re-invite received
9. TxResp          SIP/2.0 / 235 INVITE - 100 Trying
10. TxRespRel       SIP/2.0 / 235 INVITE - 200 OK
11. Rx              ACK / 235 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
12. Rx              INVITE / 236 INVITE / sip:<external number>@192.168.1.250:5060;transpo
13. ReInv           Re-invite received
14. TxResp          SIP/2.0 / 236 INVITE - 100 Trying
15. TxRespRel       SIP/2.0 / 236 INVITE - 200 OK
16. Rx              ACK / 236 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP


#pressed hold

 * SIP Call
1. Rx              INVITE / 234 INVITE / sip:<external number>@192.168.1.250;user=phone
2. NewChan         Channel SIP/network.domain.com.au-0950ae10 - fr
3. TxResp          SIP/2.0 / 234 INVITE - 100 Trying
4. TxResp          SIP/2.0 / 234 INVITE - 180 Ringing
5. TxRespRel       SIP/2.0 / 234 INVITE - 200 OK
6. Rx              ACK / 234 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
7. Rx              INVITE / 235 INVITE / sip:<external number>@192.168.1.250:5060;transpo
8. ReInv           Re-invite received
9. TxResp          SIP/2.0 / 235 INVITE - 100 Trying
10. TxRespRel       SIP/2.0 / 235 INVITE - 200 OK
11. Rx              ACK / 235 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
12. Rx              INVITE / 236 INVITE / sip:<external number>@192.168.1.250:5060;transpo
13. ReInv           Re-invite received
14. TxResp          SIP/2.0 / 236 INVITE - 100 Trying
15. TxRespRel       SIP/2.0 / 236 INVITE - 200 OK
16. Rx              ACK / 236 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP
17. Rx              INVITE / 237 INVITE / sip:<external number>@192.168.1.250:5060;transpo
18. ReInv           Re-invite received
19. TxResp          SIP/2.0 / 237 INVITE - 100 Trying
20. TxRespRel       SIP/2.0 / 237 INVITE - 200 OK
21. Rx              ACK / 237 ACK / sip:<external number>@192.168.1.250:5060;transport=TCP


Another call with SIP debug (The packets provided are when hold is pressed) - note the same 'sendrecv' SDP response:
<--- SIP read from TCP://192.168.1.208:1384 --->
INVITE sip:<external number>@192.168.1.250:5060;transport=TCP SIP/2.0
FROM: <sip:First.Last@network.domain.com.au>;epid=A4325290A1;tag=efb557905e
TO: <sip:<external number>@192.168.1.250;user=phone>;tag=as52ca7ad3
CSEQ: 236 INVITE
CALL-ID: f97f8e7a-f3e6-421b-a01d-3eb1ab3da5ac
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.1.208:1384;branch=z9hG4bK4ee02c2e
CONTACT: <sip:Mediation.network.domain.com.au:5060;transport=Tcp;maddr=192.168.1.208;ms-opaque=2cea147ecbefbb7f>
CONTENT-LENGTH: 268
SUPPORTED: 100rel
USER-AGENT: RTCC/3.0.0.0 MediationServer
CONTENT-TYPE: application/sdp; charset=utf-8

v=0
o=- 0 0 IN IP4 192.168.1.208
s=session
c=IN IP4 192.168.1.208
b=CT:1000
t=0 0
m=audio 60370 RTP/AVP 0 101
c=IN IP4 192.168.1.208
a=rtcp:60371
a=inactive
a=label:Audio
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
0
a=rtpmap:8 PCMA/8000
a=ptime:20

<------------->
--- (12 headers 18 lines) ---
Sending to 192.168.1.208 : 1384 (no NAT)

<--- Transmitting (no NAT) to 192.168.1.208:1384 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.1.208:1384;branch=z9hG4bK4ee02c2e;received=192.168.1.208
From: <sip:First.Last@network.domain.com.au>;epid=A4325290A1;tag=efb557905e
To: <sip:<external number>@192.168.1.250;user=phone>;tag=as52ca7ad3
Call-ID: f97f8e7a-f3e6-421b-a01d-3eb1ab3da5ac
CSeq: 236 INVITE
User-Agent: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:<external number>@192.168.1.250:5060;transport=TCP>
Content-Length: 0


<------------>
Audio is at 192.168.1.250 port 19698
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (no NAT) to 192.168.1.208:1384 --->
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.208:1384;branch=z9hG4bK4ee02c2e;received=192.168.1.208
From: <sip:First.Last@network.domain.com.au>;epid=A4325290A1;tag=efb557905e
To: <sip:<external number>@192.168.1.250;user=phone>;tag=as52ca7ad3
Call-ID: f97f8e7a-f3e6-421b-a01d-3eb1ab3da5ac
CSeq: 236 INVITE
User-Agent: Asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:<external number>@192.168.1.250:5060;transport=TCP>
Content-Type: application/sdp
Content-Length: 259

v=0
o=root 95282310 95282310 IN IP4 192.168.1.250
s=Asterisk PBX 1.6.0
c=IN IP4 192.168.1.250
t=0 0
m=audio 19698 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
By: Matthew Nicholson (mnicholson) 2008-12-10 16:19:10.000-0600

Can you attach sip debug (using 'sip debug on' from the asterisk CLI) of the entire transaction (start of call, hold attempt (and failure)).  Please use the file upload feature.


By: Matthew Nicholson (mnicholson) 2008-12-10 16:57:06.000-0600

Also include the DEBUG log from at least level 2 please.


By: Matthew Nicholson (mnicholson) 2008-12-10 17:33:23.000-0600

Ok.  After looking at this a little further, it appears asterisk is not honoring the new SDP data because the the SDP session version number (field 'o' is not incremented).  If this is the case you should see this message in the debug log:

SDP version number same as previous SDP

To work around this, we could add some non standard behavior to asterisk so that it ignores the session version and always treats the SDP info as new.  You should also be able to work around this by increasing the SDP version number each time a packet from your OCS server goes through your proxy.  See http://tools.ietf.org/html/rfc4566#section-5.2 for info on the format of that 'o=...' line.
By: TOC Jason (toc) 2008-12-10 17:38:47.000-0600

Can we have this as an option 'ignoresdpversion' defined at the SIP peer level?

I'll test your theory after reconfiguring opensips later tonight to rewrite the o line *currently 10am here.

I should have mentioned - I would prefer asterisk to be in place of opensips - opensips was only added to work around the bug.


By: Matthew Nicholson (mnicholson) 2008-12-10 17:42:30.000-0600

Yes, I would implement it as an option like that, probably to be supported globally and at the peer level.
By: TOC Jason (toc) 2008-12-11 22:52:10.000-0600

I have managed to resolve this issue by breaking standards.

In chan_sip.c, modify the 'else' block to always respond "TRUE" to session_modify, and remove 'exit(0)' line at the end of the if block.

Calls can be placed on hold successfully.

Of course, this behaviour breaks standards, which is really just copying what Microsoft did in the first place (broke standards).


       if (p->sessionversion_remote < 0 || p->sessionversion_remote != rua_version) {
               p->sessionversion_remote = rua_version;
               p->session_modify = TRUE;
       } else if (p->sessionversion_remote == rua_version) {
               p->session_modify = TRUE;
               ast_debug(2, "SDP version number same as previous SDP\n");
       }
By: TOC Jason (toc) 2008-12-12 08:39:58.000-0600

I'll admit defeat here - I won't be much help in fixing the issue in the source, but,  I think the below is a little better than the previous lines I posted.

It should specifically refer to packets which have 0 as the version specified in SDP.

       if (p->sessionversion_remote < 0 || p->sessionversion_remote != rua_version || rua_version == 0) {
               p->sessionversion_remote = rua_version;
               p->session_modify = TRUE;
       } else if (p->sessionversion_remote == rua_version) {
               p->session_modify = FALSE;
               ast_debug(2, "SDP version number same as previous SDP\n");
               return 0;
       }
By: Matthew Nicholson (mnicholson) 2008-12-12 15:47:48.000-0600

I have changed the severity to feature, as addressing this issue amounts to a feature request.
By: Matthew Nicholson (mnicholson) 2008-12-16 18:19:16.000-0600

Please test the patch I just uploaded.  The patch implements the 'ignoresdpversion' flag.
By: TOC Jason (toc) 2008-12-17 05:42:39.000-0600

Patch works, sort of what I was trying to put together. Thanks heaps!

The only 'notable' issue is the length of the text in the CLI output - ie:
 Ignore SDP session version: No

This causes the output to be too long to fit in with the other settings when the peer or settings are listed, and may cause issues with other users use.

Perhaps a shortened: Ignore SDP Vers. is better to ensure the CLI output isn't pushed over. In saying this, I note other variables have been abbreviated.
By: Matthew Nicholson (mnicholson) 2008-12-17 10:36:09.000-0600

Glad to hear the patch works.  I was not sure exactly what to do with the 'Ignore SDP session version:' line, but I probably will need to abbreviate it.  I am going to post this patch on reviewboard for review before committing it.
By: Digium Subversion (svnbot) 2008-12-17 12:49:09.000-0600

Repository: asterisk
Revision: 165180

U   trunk/CHANGES
U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample

------------------------------------------------------------------------
r165180 | mnicholson | 2008-12-17 12:49:08 -0600 (Wed, 17 Dec 2008) | 14 lines

This patch adds a new 'ignoresdpversion' option to sip.conf.  When this is
enabled (either globally or for a specific peer), chan_sip will treat any SDP
data it receives as new data and update the media stream accordingly.  By
default, Asterisk will only modify the media stream if the SDP session version
received is different from the current SDP session version.  This option is
required to interoperate with devices that have non-standard SDP session
version implementations (observed by toc on the bug tracker with Microsoft OCS
which always uses 0 as the session version).

http://reviewboard.digium.com/r/94
(closes issue ASTERISK-13112)
Reported by: toc
Tested by: toc

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

http://svn.digium.com/view/asterisk?view=rev&revision=165180
By: Digium Subversion (svnbot) 2008-12-17 12:55:11.000-0600

Repository: asterisk
Revision: 165180

U   trunk/CHANGES
U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample

------------------------------------------------------------------------
r165180 | mnicholson | 2008-12-17 12:49:12 -0600 (Wed, 17 Dec 2008) | 14 lines

This patch adds a new 'ignoresdpversion' option to sip.conf.  When this is
enabled (either globally or for a specific peer), chan_sip will treat any SDP
data it receives as new data and update the media stream accordingly.  By
default, Asterisk will only modify the media stream if the SDP session version
received is different from the current SDP session version.  This option is
required to interoperate with devices that have non-standard SDP session
version implementations (observed by toc on the bug tracker with Microsoft OCS
which always uses 0 as the session version).

http://reviewboard.digium.com/r/94/
(closes issue ASTERISK-13112)
Reported by: toc
Tested by: toc

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

http://svn.digium.com/view/asterisk?view=rev&revision=165180
By: Digium Subversion (svnbot) 2009-06-15 16:20:42

Repository: asterisk
Revision: 200707

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c
U   branches/1.6.1/configs/sip.conf.sample

------------------------------------------------------------------------
r200707 | kpfleming | 2009-06-15 16:20:41 -0500 (Mon, 15 Jun 2009) | 35 lines

Merged revisions 165180,200689 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r165180 | mnicholson | 2008-12-17 12:49:12 -0600 (Wed, 17 Dec 2008) | 14 lines
 
 This patch adds a new 'ignoresdpversion' option to sip.conf.  When this is
 enabled (either globally or for a specific peer), chan_sip will treat any SDP
 data it receives as new data and update the media stream accordingly.  By
 default, Asterisk will only modify the media stream if the SDP session version
 received is different from the current SDP session version.  This option is
 required to interoperate with devices that have non-standard SDP session
 version implementations (observed by toc on the bug tracker with Microsoft OCS
 which always uses 0 as the session version).
 
 http://reviewboard.digium.com/r/94/
 (closes issue ASTERISK-13112)
 Reported by: toc
 Tested by: toc
........
 r200689 | kpfleming | 2009-06-15 15:42:38 -0500 (Mon, 15 Jun 2009) | 12 lines
 
 Accept T.38 re-INVITE responses with invalid SDP versions.
 
 This commit changes the 'incoming SDP version' check logic a bit more; when
 'ignoresdpversion' is *not* set for a peer, if we initiate a re-INVITE to
 switch to T.38, we'll always accept the peer's SDP response, even if they
 don't properly increment the SDP version number as they should. If this situation
 occurs, a warning message will be generated suggesting that the peer's
 configuration be changed to include the 'ignoresdpversion' configuration option
 (although ideally they'd fix their SIP implementation to be RFC compliant).
 
 AST-221
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=200707
By: Digium Subversion (svnbot) 2009-06-15 16:29:27

Repository: asterisk
Revision: 200724

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c
U   branches/1.6.0/configs/sip.conf.sample

------------------------------------------------------------------------
r200724 | kpfleming | 2009-06-15 16:29:27 -0500 (Mon, 15 Jun 2009) | 35 lines

Merged revisions 165180,200689 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r165180 | mnicholson | 2008-12-17 12:49:12 -0600 (Wed, 17 Dec 2008) | 14 lines
 
 This patch adds a new 'ignoresdpversion' option to sip.conf.  When this is
 enabled (either globally or for a specific peer), chan_sip will treat any SDP
 data it receives as new data and update the media stream accordingly.  By
 default, Asterisk will only modify the media stream if the SDP session version
 received is different from the current SDP session version.  This option is
 required to interoperate with devices that have non-standard SDP session
 version implementations (observed by toc on the bug tracker with Microsoft OCS
 which always uses 0 as the session version).
 
 http://reviewboard.digium.com/r/94/
 (closes issue ASTERISK-13112)
 Reported by: toc
 Tested by: toc
........
 r200689 | kpfleming | 2009-06-15 15:42:38 -0500 (Mon, 15 Jun 2009) | 12 lines
 
 Accept T.38 re-INVITE responses with invalid SDP versions.
 
 This commit changes the 'incoming SDP version' check logic a bit more; when
 'ignoresdpversion' is *not* set for a peer, if we initiate a re-INVITE to
 switch to T.38, we'll always accept the peer's SDP response, even if they
 don't properly increment the SDP version number as they should. If this situation
 occurs, a warning message will be generated suggesting that the peer's
 configuration be changed to include the 'ignoresdpversion' configuration option
 (although ideally they'd fix their SIP implementation to be RFC compliant).
 
 AST-221
........

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

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