200 OK response is changing RTP port from reINVITE

request – Why ??
m1keyboy (TechnicalUser)
(OP)
4 Jun 09 10:19
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 (Programmer)8 Jun 09 12:48
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 (TechnicalUser)
(OP)
20 Jul 09 06:09
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:[email protected]>;tag=0_3476996592-88804956
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: "D.Jones" <sip:[email protected]: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:[email protected]:5060;transport=udp>
To: <sip:[email protected]>;tag=e40d4659
From: "D.Jones"<sip:[email protected]>;tag=0_3476996592-88804956
Call-ID: [email protected]
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:[email protected]:5060>
To: <sip:[email protected]>
From: "D.Jones"<sip:[email protected]>;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:[email protected]>;tag=e349b009
To: <sip:[email protected]>;tag=0_3485976592-88804958
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 1 INVITE
Supported: timer
Contact: <sip:[email protected]: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:[email protected]:5060>
To: <sip:[email protected]>;tag=0_3485976592-88804958
From: "D.Jones"<sip:[email protected]>;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:[email protected]:5060;transport=udp>
To: "D.Jones"<sip:[email protected]>;tag=0_3476996592-88804956
From: <sip:[email protected]>;tag=e40d4659
Call-ID: [email protected]
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:[email protected]>;tag=e349b009
To: <sip:[email protected]>;tag=0_3485976592-88804958
Call-ID: OGI0NTU4YTEyMDUxZGQwNGJlZWM0ZTkwYWVmZTE3ODQ.
CSeq: 2 INVITE
Supported: timer
Contact: <sip:[email protected]: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:[email protected]>;tag=e40d4659
To: "D.Jones" <sip:[email protected]>;tag=0_3476996592-88804956
Call-ID: [email protected]
CSeq: 2 INVITE
Supported: timer
Contact: "D.Jones" <sip:[email protected]: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:[email protected]:5060>
To: <sip:[email protected]>;tag=0_3485976592-88804958
From: "D.Jones"<sip:[email protected]>;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 (Programmer)20 Jul 09 14:58
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 (MIS)20 Jul 09 16:33
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 (Programmer)20 Jul 09 18:00
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... ;)