[Home]

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-0600Date Closed:2011-06-07 14:07:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.4.13-working.txt
( 1) 1.6.0.3-broken.txt
( 2) 1.6.0.3-working.txt
Description:Hi there

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 1.6.0.3, 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://87.238.72.153:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.232.93.17:5060;branch=z9hG4bK5db6285d;rport=5060
From: <sip:448450045413@b.e164.org.uk>;tag=as2d0f15a6
To: <sip:07743898503@87.238.72.155>;tag=7DDF1164-A72
Date: Thu, 19 Feb 2009 16:41:49 gmt
Call-ID: 7C8E6A1-FDDB11DD-86EBE542-CAA4DB9B@87.238.72.155
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:07743898503@87.238.72.155>;party=called;screen=yes;privacy=off
Contact: <sip:07743898503@87.238.72.155:5060>
Record-Route: <sip:87.238.72.153;lr=on;ftag=as2d0f15a6>
Content-Type: application/sdp
Content-Length: 249

v=0
o=CiscoSystemsSIP-GW-UserAgent 9676 3773 IN IP4 87.238.72.155
s=SIP Call
c=IN IP4 87.238.72.155
t=0 0
m=audio 18800 RTP/AVP 3 101
c=IN IP4 87.238.72.155
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:10

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:

[outbound]
type=peer
host=gk.magrathea.net
username=XXXXXXXX
secret=XXXXXXXX
authname=XXXXXXXX
canreinvite=yes
context=main
disallow=all
allow=alaw
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

Doh...

When we upgraded to 1.6.0.3 it overwrote the

disallow=all
allow=alaw

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

Hi there,

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.