|Summary:||ASTERISK-13611: SIP REINVITE broken in 1.6 (was working in 1.4.13)|
|Reporter:||Matt King, M.A. Oxon. (kebl0155)||Labels:|
|Date Opened:||2009-02-19 12:26:54.000-0600||Date Closed:||2011-06-07 14:07:21|
|Environment:||Attachments:||( 0) 1.4.13-working.txt|
( 1) 126.96.36.199-broken.txt
( 2) 188.8.131.52-working.txt
We take SIP calls from a variety of different gateways from a single provider.
With 1.4.13, we were able to use canreinvite to drop out of the audio stream.
With 184.108.40.206, reinvite results in no audio with some of their gateways, and not others.
There is at least one difference in the SIP conversation between the two gateways.
****** ADDITIONAL INFORMATION ******
I've attached three SIP/RTP logs.
The first is a 1.6 log with reinvite working with one of the gateways.
The second is a 1.6 log with reinvite broken with one of the other gateways.
The third is a 1.4 log with reinivite working, with the same gateway that breaks 1.6.
I can only see one difference in the streams between the two gateways, which is an extra Record-Route header in the following message:
<--- SIP read from UDP://220.127.116.11:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 18.104.22.168:5060;branch=z9hG4bK5db6285d;rport=5060
Date: Thu, 19 Feb 2009 16:41:49 gmt
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
o=CiscoSystemsSIP-GW-UserAgent 9676 3773 IN IP4 22.214.171.124
c=IN IP4 126.96.36.199
m=audio 18800 RTP/AVP 3 101
c=IN IP4 188.8.131.52
I don't know whether this extra is the cause of the error or not - it's possible I've missed something else that's different.
I also don't know whether this Record-Route header is supposed to be there or not - all I know is that it was working with 1.4.13, and is now not working, hence this bug post.
Many thanks for your assistance.
|Comments:||By: Paul Belanger (pabelanger) 2009-02-19 13:44:25.000-0600|
What does your sip.conf look like?
By: Matt King, M.A. Oxon. (kebl0155) 2009-02-20 04:35:40.000-0600
Here's the relevant section:
By: Mark Michelson (mmichelson) 2009-03-04 14:38:52.000-0600
The biggest difference I'm noticing between the working and non-working scenarios is in codecs in the SDPs of the reinvites. In both working scenarios, the only codec in the offers and answers is alaw. In the non-working scenario, Asterisk offers gsm, ulaw, and alaw to one party (and receives an answer with gsm only) and offers only alaw to the other party. It may be this codec mismatch which is causing the problem to occur.
By: Matt King, M.A. Oxon. (kebl0155) 2009-03-05 06:41:38.000-0600
When we upgraded to 184.108.40.206 it overwrote the
section in the general section of our sip.conf
Restoring these lines does seem to have fixed the problem. Sorry, this is looking like my bad.
I'll try this with a live customer tomorrow (just to be sure) and report back.
By: Mark Michelson (mmichelson) 2009-03-05 10:09:50.000-0600
No problem. Let us know how it goes.
By: Mark Michelson (mmichelson) 2009-03-09 14:42:39
It's been a few days. I was wondering how the test went with the customer? Can we close this issue or is there still a problem?
By: Matt King, M.A. Oxon. (kebl0155) 2009-03-09 14:49:14
They did have a problem today but I don't think it's related. Can we give it one more day to be sure?
By: Mark Michelson (mmichelson) 2009-03-09 14:51:10
Sure, there's no rush. Your previous note had implied that you only needed a day to test, which is why I pinged the issue.
By: Matt King, M.A. Oxon. (kebl0155) 2009-03-11 14:11:44
No problems at all today - I think it's safe to close this one.
By: Joshua C. Colp (jcolp) 2009-03-11 14:35:12
Closed per reporter.