SIP 183 after a 200ok message

Asterisk Asterisk Support
1

One of our providers send the following sequence after we send a dial (INVITE) message (SIP):
A: us
B: Provider

1- Initial invite (from A - > B)
2- SIP 183 with SDP (B -> A)
3- SIP 200 with SDP (B -> A)
4- SIP 183 with SDP (B -> A)

Our server DOES update the RTP based on the SDP only up to 3. However, it just ignores the SDP data in 4. It seems that Asterisk ignores any SDP (within 183 messages) after receiving a 200 SIP ok.

Can anyone confirm this? I couldn’t find anything in the RFC that says this should be the case.

2

A 200 message ends the transaction. Subsequent updates to the dialog must be done with a re-invite, update or refer. The preferred method in the carrier world is reinvite.

It sounds like your upstream provider is not following RFC. I’ve never heard of anyone sending a 183 after the 200ok.

3

Would you please direct me to something in the rfc that says so?

4

A 200ok is a final response, it’s all over the RFC. Any updates after a final response must be done in accordance with the methods I stated before. Here are a few places that might be useful to you. Also check out all of section 12.3 in the RFC.

Rosenberg, et. al. Standards Track [Page 82]

RFC 3261 SIP: Session Initiation Protocol June 2002

The UAC core considers the INVITE transaction completed 64*T1 seconds
after the reception of the first 2xx response. At this point all the
early dialogs that have not transitioned to established dialogs are
terminated. Once the INVITE transaction is considered completed by
the UAC core, no more new 2xx responses are expected to arrive.

If, after acknowledging any 2xx response to an INVITE, the UAC does
not want to continue with that dialog, then the UAC MUST terminate
the dialog by sending a BYE request as described in Section 15.

Also Read:

Rosenberg, et. al. Standards Track [Page 85]

RFC 3261 SIP: Session Initiation Protocol June 2002

Section 14, for dealing with modifying existing dialogs

5

How does it detect sip packets that arrive out of order? i.e. let’s say the 183 message was actually sent before the 200 one but it arrives later (network issue or whatever). Does Asterisk use the session_id in SDP to detect this? (or does it just ignore anything after the 200 message)

The behavior that we get is that message (4) comes just milliseconds after (3) and it gets ignored.

6

Here is a trace of what we get:

Audio is at 64.34.xxx.xxx port 15802
Adding codec 0x100 (g729) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 77.72.yyy.yyy:5060:
INVITE sip:001416DDDDDDD@sip.voicetrading.com SIP/2.0
Via: SIP/2.0/UDP 64.34.xxx.xxx:5060;branch=z9hG4bK531e632c
From: “416SSSSSSS” sip:416SSSSSSS@64.34.xxx.xxx;tag=as3c371998
To: sip:001416DDDDDDD@sip.voicetrading.com
Contact: sip:416SSSSSSS@64.34.xxx.xxx
Call-ID: 7b96a9452622bb8e7b282c8104ea34a7@64.34.xxx.xxx
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Wed, 16 Feb 2011 03:02:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 260

v=0
o=root 3015 3015 IN IP4 64.34.xxx.xxx
s=session
c=IN IP4 64.34.xxx.xxx
t=0 0
m=audio 15802 RTP/AVP 18 0 101

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

-- Called 001416DDDDDDD@voicetrading

<— SIP read from 77.72.yyy.yyy:5060 —>

SIP/2.0 183 Session progress
Via: SIP/2.0/UDP 64.34.xxx.xxx:5060;branch=z9hG4bK531e632c
From: “416SSSSSSS” sip:416SSSSSSS@64.34.xxx.xxx;tag=as3c371998
To: sip:001416DDDDDDD@sip.voicetrading.com;tag=3b0113ac4d540deaa59f8
Contact: sip:001416DDDDDDD@77.72.yyy.yyy:5060
Call-ID: 7b96a9452622bb8e7b282c8104ea34a7@64.34.xxx.xxx
CSeq: 102 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Type: application/sdp
Content-Length: 219

v=0
o=CARRIER 1297825333 1297825333 IN IP4 77.72.aaa.aaa
s=SIP Call
c=IN IP4 77.72.aaa.aaa
t=0 0
m=audio 57900 RTP/AVP 18 101

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=ptime:20

<------------->
— (11 headers 10 lines) —
Found RTP audio format 18
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 77.72.aaa.aaa:57900
– SIP/voicetrading-00000000 is making progress passing it to IAX2/174.133.195.194:4569-392

… There is some wait here … dial is in progress …

<— SIP read from 77.72.yyy.yyy:5060 —>
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 64.34.xxx.xxx:5060;branch=z9hG4bK531e632c
From: “416SSSSSSS” sip:416SSSSSSS@64.34.xxx.xxx;tag=as3c371998
To: sip:001416DDDDDDD@sip.voicetrading.com;tag=3b0113ac4d540deaa59f8
Contact: sip:001416DDDDDDD@77.72.yyy.yyy:5060
Call-ID: 7b96a9452622bb8e7b282c8104ea34a7@64.34.xxx.xxx
CSeq: 102 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Type: application/sdp
Content-Length: 219

v=0
o=CARRIER 1297825337 1297825337 IN IP4 77.72.aaa.aaa
s=SIP Call
c=IN IP4 77.72.aaa.aaa
t=0 0
m=audio 57900 RTP/AVP 18 101

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=ptime:20

<------------->
— (11 headers 10 lines) —
Found RTP audio format 18
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x100 (g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 77.72.aaa.aaa:57900
list_route: hop: sip:001416DDDDDDD@77.72.yyy.yyy:5060
set_destination: Parsing sip:001416DDDDDDD@77.72.yyy.yyy:5060 for address/port to send to
set_destination: set destination to 77.72.yyy.yyy, port 5060
Transmitting (NAT) to 77.72.yyy.yyy:5060:
ACK sip:001416DDDDDDD@77.72.yyy.yyy:5060 SIP/2.0
Via: SIP/2.0/UDP 64.34.xxx.xxx:5060;branch=z9hG4bK0cfa9a40
From: “416SSSSSSS” sip:416SSSSSSS@64.34.xxx.xxx;tag=as3c371998
To: sip:001416DDDDDDD@sip.voicetrading.com;tag=3b0113ac4d540deaa59f8
Contact: sip:416SSSSSSS@64.34.xxx.xxx
Call-ID: 7b96a9452622bb8e7b282c8104ea34a7@64.34.xxx.xxx
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0

<— SIP read from 77.72.yyy.yyy:5060 —>

SIP/2.0 183 Session progress
Via: SIP/2.0/UDP 64.34.xxx.xxx:5060;branch=z9hG4bK531e632c
From: “416SSSSSSS” sip:416SSSSSSS@64.34.xxx.xxx;tag=as3c371998
To: sip:001416DDDDDDD@sip.voicetrading.com;tag=3b0113ac4d540deaa59f8
Contact: sip:001416DDDDDDD@77.72.yyy.yyy:5060
Call-ID: 7b96a9452622bb8e7b282c8104ea34a7@64.34.xxx.xxx
CSeq: 102 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Type: application/sdp
Content-Length: 226

v=0
o=CARRIER 1297825337 1297825337 IN IP4 208.167.bbb.bbb
s=SIP Call
c=IN IP4 208.167.bbb.bbb
t=0 0
m=audio 8396 RTP/AVP 18 101

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=ptime:20

<------------->
— (11 headers 10 lines) —

^^^^ at the end, there is no “Found RTP audio format 18” … shows that asterisk has ignored the message.

In the debug outputs, there is a line:

(Provisional) Stopping retransmission (but retaining packet) on '7b96a9452622bb8e7b282c8104ea34a7@64.34.xxx.xxx’ Request 102: Found

7

first come first serve, it’s not going to hold out for a better deal :smile:

I don’t fully understand the problem though. 183 messages are sent if the far end wishes to play early media, like an auto attendant instead of ringing. Once the call is 200ok’d this means you’re talking to the person you called. Why does a lagging early media packet matter?

Now if they’re trying to get you to talk on a different, IP, port, codec, etc after the call is setup, that’s different. That has to be done with a reinvite, it’s not got to get done with a provisional response like 183.

8

The issue that we have is that our provider assumes that the last SDP dictates the IP/port/codec. They ‘assume’ that we receive this SDP in the last 183 message which they think they sent before the 200ok one. So, they expect that we use the IP/port/codec that they sent in (4) but Asterisk ignores it because it came out of order (after 200).

So, our Asterisk box is using the IP/Port/Codec that was described in (3) whereas our provider expects us to use the IP/Port/Codec that was sent in (4). They actually seem to be sending the 4th message before the 3rd one but for whatever reason we receive it after that.

9

I just found the flaw in my last argument.

You are absolutely right. I am going to file a ticket on our provider’s portal.

Thank you very much for the help.

10

Out of curiosity, isn’t RE-INVITE the method for the initiator of the SIP (the party that sent the invite originally) to modify media channels? How does the other end can update the media channel after a 200 is sent and channel established?

11

Either end can do a re-invite. UAC and UAS roles only exist for the dialogue.