200 OK response is changing RTP port from reINVITE request - why?

[m1keyboy]

Hi,

We've connected a third-party 'dialler' system to a Mitel 3300 via a SIP trunk. The general callflow of a basic A-->B call when using this system is:

1. Endpoint A dials access number to reach 3rd party dialler
2. Endpoint A requests Endpoint B whilst connected to 3rd party dialler
3. 3rd party dialler sends this request to the Mitel, which forwards it on to Endpoint B
4. Endpoint B answers, and is 'connected' (i.e. RTP redirected) to Endpoint A with the use of reINVITE's.

This works, however; when the Mitel responds with a couple of 200 OK's to the reINVITE's sent by the 3rd party dialler, the SDP body information contains different ports to the ones specified in the initial reINVITE. Because of this, the 3rd party dialler is infinitely sending reINVITE's to notify the other Endpoint of the port change (one big reINVITE loop basically) - and thus the audio is extremely choppy.

We've connected this 3rd party dialler to a number of other systems (CCM, Asterisk, CS1000, HiPath8000) and not seen this before - the port that comes back in the 200 OK SDP information is always the same as the one specified in the original reINVITE.

Does anyone know why the Mitel (or the Mitel endpoints?) would need to constantly try and change the RTP port? A normal Endpoint A to Endpoint B call works fine without the 3rd party dialler. And more importantly, does anyone know how (if?) we can configure the Mitel to NOT change the RTP port when responding to a reINVITE request?

This was seen on v9.0.2.28.

 

[IrwinMFletcher]

From my SIP understanding, which is not a the highest level...A ReInvite is a request to make a change to the current call, and as part of that, any and all parameters are up for grab. So it's within the spec to alter the port.

I'm not exactly following the scenario though, can you post the messaging? My guess is that it's switching from streaming from the set to the controller for MOH and back again.

 

[m1keyboy]

Hi IrwinMFletcher,

Thanks for the response.

It seems a little strange that the Mitel responds with a '200 OK' to the RE-INVITE request, yet changes the RTP port in the SDP body (...so, it's not 'OK'! ).

Here's what the messaging looks like:

--> Initial INVITE from the Mitel

Message Header
Via: SIP/2.0/UDP 192.168.53.101:5060;branch=z9hG4bK3476996592-88804955
Max-Forwards: 70
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Supported: timer,replaces
From: "D.Jones" <sip:+8771@192.168.53.101>;tag=0_3476996592-88804956
To: <sip:+7400@192.168.53.212>
Call-ID: 3476996592-88804954@192.168.53.101
CSeq: 1 INVITE
Contact: "D.Jones" <sip:+8771@192.168.53.101:5060;transport=udp>
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 9.0.2.28
Content-Length: 209

Message Body
v=0
o=- 4854 4854 IN IP4 192.168.53.113
s=-
c=IN IP4 192.168.53.113
t=0 0
m=audio 50024 RTP/AVP 8 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<--- 100 Trying

<--- 180 Ringing

<--- 200 OK (with SDP)

Message Header
Via: SIP/2.0/UDP 192.168.53.101:5060;branch=z9hG4bK3476996592-88804955
Require: timer
Contact: <sip:+7400@192.168.53.212:5060;transport=udp>
To: <sip:+7400@192.168.53.212>;tag=e40d4659
From: "D.Jones"<sip:+8771@192.168.53.101>;tag=0_3476996592-88804956
Call-ID: 3476996592-88804954@192.168.53.101
CSeq: 1 INVITE
Session-Expires: 90;refresher=uas
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
Content-Type: application/sdp
Supported: timer
User-Agent: dialler
Content-Length: 215

Message Body
v=0
o=tpcore 16777717 2 IN IP4 192.168.53.212
s=call
c=IN IP4 192.168.53.212
t=0 0
m=audio 10016 RTP/AVP 8 101
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

---> ACK

<--- INVITE (3rd party dialler making a call via the Mitel)

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-ca06f84d4d4af24b-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:8771@192.168.53.212:5060>
To: <sip:8773@192.168.53.101>
From: "D.Jones"<sip:8771@192.168.53.101>;tag=e349b009
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 1 INVITE
Session-Expires: 90
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
Content-Type: application/sdp
Supported: timer
User-Agent: dialler
Content-Length: 215

Message Body
v=0
o=tpcore 16777717 2 IN IP4 192.168.53.212
s=call
c=IN IP4 192.168.53.212
t=0 0
m=audio 10052 RTP/AVP 8 101
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

---> 100 Trying

---> 180 Ringing

---> 200 OK (with SDP)

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-ca06f84d4d4af24b-1---d8754z-;rport
From: "D.Jones" <sip:8771@192.168.53.101>;tag=e349b009
To: <sip:8773@192.168.53.101>;tag=0_3485976592-88804958
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 1 INVITE
Supported: timer
Contact: <sip:8773@192.168.53.101:5060;transport=udp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 9.0.2.28
Content-Length: 160

Message Body
v=0
o=- 4855 4855 IN IP4 192.168.53.126
s=-
c=IN IP4 192.168.53.126
t=0 0
m=audio 50306 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<--- ACK

<--- RE-INVITE to endpoint A (3rd party dialler attempting to re-negotiate the media between the two endpoints)

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-0c141c249c0e4861-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:8771@192.168.53.212:5060>
To: <sip:8773@192.168.53.101>;tag=0_3485976592-88804958
From: "D.Jones"<sip:8771@192.168.53.101>;tag=e349b009
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 2 INVITE
Session-Expires: 90;refresher=uac
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
Content-Type: application/sdp
Supported: timer
User-Agent: dialler
Content-Length: 215

Message Body
v=0
o=tpcore 16777717 3 IN IP4 192.168.53.212
s=call
c=IN IP4 192.168.53.113
t=0 0
m=audio 50024 RTP/AVP 8 101
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

<--- RE-INVITE to endpoint B (3rd party dialler attempting to re-negotiate the media between the two endpoints)

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-f53dd41e800cda01-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:+7400@192.168.53.212:5060;transport=udp>
To: "D.Jones"<sip:+8771@192.168.53.101>;tag=0_3476996592-88804956
From: <sip:+7400@192.168.53.212>;tag=e40d4659
Call-ID: 3476996592-88804954@192.168.53.101
CSeq: 2 INVITE
Session-Expires: 90;refresher=uac
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
Content-Type: application/sdp
Supported: timer
User-Agent: dialler
Content-Length: 215

Message Body
v=0
o=tpcore 16777717 3 IN IP4 192.168.53.212
s=call
c=IN IP4 192.168.53.126
t=0 0
m=audio 50306 RTP/AVP 8 101
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

---> 100 Trying

---> 100 Trying

---> 200 OK (with SDP) - The Mitel responding 'OK' to the RE-INVITE request for endpoint A. It's changed the audio port to 50362, instead of 50024 which was specified in the RE-INVITE request.

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-0c141c249c0e4861-1---d8754z-;rport
From: "D.Jones" <sip:8771@192.168.53.101>;tag=e349b009
To: <sip:8773@192.168.53.101>;tag=0_3485976592-88804958
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 2 INVITE
Supported: timer
Contact: <sip:8773@192.168.53.101:5060;transport=udp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 9.0.2.28
Content-Length: 160

Message Body
v=0
o=- 4855 4856 IN IP4 192.168.53.126
s=-
c=IN IP4 192.168.53.126
t=0 0
m=audio 50362 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<--- ACK

---> 200 OK (with SDP) - The Mitel responding 'OK' to the RE-INVITE request for endpoint B. It's changed the audio port to 50422, instead of 50306 which was specified in the RE-INVITE request.

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-f53dd41e800cda01-1---d8754z-;rport
From: <sip:+7400@192.168.53.212>;tag=e40d4659
To: "D.Jones" <sip:+8771@192.168.53.101>;tag=0_3476996592-88804956
Call-ID: 3476996592-88804954@192.168.53.101
CSeq: 2 INVITE
Supported: timer
Contact: "D.Jones" <sip:+8771@192.168.53.101:5060;transport=udp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 9.0.2.28
Content-Length: 160

Message Body
v=0
o=- 4854 4855 IN IP4 192.168.53.113
s=-
c=IN IP4 192.168.53.113
t=0 0
m=audio 50422 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<--- ACK

<--- RE-INVITE (3rd party dialler sending a RE-INVITE request back to endpoint A using port 50422 for audio - the same one endpoint B requested to use in it's 200 OK response to the initial RE-INVITE request)

Message Header
Via: SIP/2.0/UDP 192.168.53.212:5060;branch=z9hG4bK-d8754z-cd331040ff1aab65-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:8771@192.168.53.212:5060>
To: <sip:8773@192.168.53.101>;tag=0_3485976592-88804958
From: "D.Jones"<sip:8771@192.168.53.101>;tag=e349b009
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 3 INVITE
Session-Expires: 90;refresher=uac
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
Content-Type: application/sdp
Supported: timer
User-Agent: dialler
Content-Length: 215

Message Body
v=0
o=tpcore 16777717 4 IN IP4 192.168.53.212
s=call
c=IN IP4 192.168.53.113
t=0 0
m=audio 50422 RTP/AVP 8 101
a=fmtp:101 0-15
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

---> Trying

---> 200 OK (with SDP) - it's changed the audio port again, let's notify endpoint B etc etc.

This may be perfectly acceptable, but we've never encountered this before (the port stated in the initial RE-INVITE requests isn't changed in the corresponding OK requests). A couple of questions:

1) Is anyone able to point me in the direction of some documentation which clarifies if this is acceptable behaviour?

2) Is there anything I can do at the Mitel end to STOP it changing the RTP audio port in it's 200 OK response to the RE-INVITEs?

Cheers,

Mike.

 

[IrwinMFletcher]

From the SIP Protocol...

14 Modifying an Existing Session


A successful INVITE request (see Section 13) establishes both a
dialog between two user agents and a session using the offer-answer
model. Section 12 explains how to modify an existing dialog using a
target refresh request (for example, changing the remote target URI
of the dialog). This section describes how to modify the actual
session. This modification can involve changing addresses or ports,
adding a media stream, deleting a media stream, and so on. This is
accomplished by sending a new INVITE request within the same dialog
that established the session. An INVITE request sent within an
existing dialog is known as a re-INVITE.

Note that a single re-INVITE can modify the dialog and the
parameters of the session at the same time.

Either the caller or callee can modify an existing session.

The behavior of a UA on detection of media failure is a matter of
local policy. However, automated generation of re-INVITE or BYE is
NOT RECOMMENDED to avoid flooding the network with traffic when there
is congestion. In any case, if these messages are sent
automatically, they SHOULD be sent after some randomized interval.

Note that the paragraph above refers to automatically generated
BYEs and re-INVITEs. If the user hangs up upon media failure, the
UA would send a BYE request as usual.



....

Once you open up a re-invite, then any of the session parameters are open for negotiation.
There is no way to handle what you are asking that I know of, the reason it jumps ports is that the ports are allocated from the E2T (I'm guessing by the 50000 port range showing, I don't know the nature of your Mitel endpoint). Every time a new one is requested, it will get a new port to try to help eliminate zombie phones from streaming on the port. For example, say your dialer is running G729, and it negotiates between the endpoints G711, there would be a transient condition between the two where the endpoint wouldn't know who/what endpoint it should be receiving from. It becomes even worse when you throw in encryption.

 

[slapin]

I'm with Irwin. It is logical if re-Invite will change session parameters, then peer can do the same in 200 OK as well for any reasons. There is nothing wrong about it. The other story is how vendors are implementing this.

 

[IrwinMFletcher]

One thing I should have asked was the version. There were a lot of SIP changes within the 9.0 UR releases, you may want to check those.

SIP is really the wild west, with the 'protocol' open to interpretation in many areas. The implementer with the biggest club often wins, so if enough 3rd party devices require the ports to remain the same on the re-invites then it may have been changed in a later release. I would still maintain that this is still allowed under the specification, it's just sometimes it's hard to get the big boys to play nice...