Lync Multipart SDP and media port selection

We are developing a federation system between lync to lync.

While testing voice calls between federated partners, we see that originating Lync is sending a multipart SDP, both having different ports, 50008 in the first and 50014 in the second.

------=_NextPart_000_0029_01D09FB4.3168B620
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <1d8c73228ae616f75ec9e03222a3bd73@ucfed.net>
Content-Dis; handling=optional; ms-proxy-2007fallback

v=0
o=- 0 0 IN IP4 10.203.28.69
s=session
c=IN IP4 10.203.28.69
b=CT:99980
t=0 0
m=audio 50008 RTP/AVP 117 114 9 112 111 0 8 116 115 97 13 118 101
a=candidate:HpE8yl64hfxrOOzwtIxfKP7+mblqi2TPjJCNlV7wxSQ 1 vCszcsLoH/+uBZWEAswz0A UDP 0.830 10.8.0.30 50004 
a=candidate:HpE8yl64hfxrOOzwtIxfKP7+mblqi2TPjJCNlV7wxSQ 2 vCszcsLoH/+uBZWEAswz0A UDP 0.830 10.8.0.30 50005 
a=candidate:5lgBKF+7BZZXK83f/2shtlt4h5oBMkMlDKDawZXSSNY 1 v0BUuQgVyRvm3ndw9urljw UDP 0.840 10.203.28.69 50008 
a=candidate:5lgBKF+7BZZXK83f/2shtlt4h5oBMkMlDKDawZXSSNY 2 v0BUuQgVyRvm3ndw9urljw UDP 0.840 10.203.28.69 50009 
a=candidate:gyvBMbh5EepyodNY+mdte5BtBnhyOTcLI0DTFbq9cKI 1 UF/ZIbyimNGCrV3hh3yo2w TCP 0.110 66.119.158.50 52304 
a=candidate:gyvBMbh5EepyodNY+mdte5BtBnhyOTcLI0DTFbq9cKI 2 UF/ZIbyimNGCrV3hh3yo2w TCP 0.110 66.119.158.50 52304 
a=candidate:rR6ugy21vw51W6J0k47inGD5iwXsdoY2WnrNE9TSlKI 1 Yvm9STQj0sCPtNieLMW5og TCP 0.250 66.119.158.126 36591 
a=candidate:rR6ugy21vw51W6J0k47inGD5iwXsdoY2WnrNE9TSlKI 2 Yvm9STQj0sCPtNieLMW5og TCP 0.250 66.119.158.126 36591 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:SB/2xNbP7SEU7NLjDYafYpsv6SQbLPdY/I6dakIj|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:o+Br0DwMXqrfl/MnZhHeerHVao2irQTuTpiW/6p3|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:I9xE3Vk9KIo2wbVq+YhMBow1pUMezuR0nGb2dGYW|2^31
a=maxptime:200
a=rtpmap:117 G722/8000/2
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 AAL2-G726-32/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=x-bypassid:73a9684f-3994-4107-9ca8-4b69ea381cb3

------=_NextPart_000_0029_01D09FB4.3168B620
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <8ed95d6b446d08269c4d0d6e08da88a6@ucfed.net>
Content-Dis handling=optional

v=0
o=- 0 1 IN IP4 10.203.28.69
s=session
c=IN IP4 10.203.28.69
b=CT:99980
t=0 0
a=x-devicecaps:audio:send,recv;video:recv
m=audio 50014 RTP/AVP 117 114 9 112 111 0 8 116 115 97 13 118 101
a=x-ssrc-range:2447635456-2447635456
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp-rsize
a=label:main-audio
a=x-source:main-audio
a=ice-ufrag:uCRg
a=ice-pwd:9XTuC/+aLbVY4n8xYREbsQJo
a=candidate:1 1 UDP 2130706431 10.203.28.69 50014 typ host 
a=candidate:1 2 UDP 2130705918 10.203.28.69 50015 typ host 
a=candidate:2 1 UDP 2130705919 10.8.0.30 50014 typ host 
a=candidate:2 2 UDP 2130705406 10.8.0.30 50015 typ host 
a=candidate:3 1 TCP-ACT 1684798463 10.203.28.69 50014 typ srflx raddr 10.203.28.69 rport 50014 
a=candidate:3 2 TCP-ACT 1684797950 10.203.28.69 50014 typ srflx raddr 10.203.28.69 rport 50014 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:SB/2xNbP7SEU7NLjDYafYpsv6SQbLPdY/I6dakIj|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:o+Br0DwMXqrfl/MnZhHeerHVao2irQTuTpiW/6p3|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:I9xE3Vk9KIo2wbVq+YhMBow1pUMezuR0nGb2dGYW|2^31
a=maxptime:200
a=rtpmap:117 G722/8000/2
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 AAL2-G726-32/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=x-bypassid:73a9684f-3994-4107-9ca8-4b69ea381cb3

------=_NextPart_000_0029_01D09FB4.3168B620--

Our media gateway that handles the RTP packets, doesn't support multipart SDP, and thus we forward only the first SDP to it (containing the port 50008). SIP signalling is successful. But at the time of RTP establishment, we see that most of the times, originating lync client chooses the port it specified in the first SDP, but sometimes it chooses the port specified in the second SDP (50014). Now this port is not known to our media gateway, as we forwarded only the first SDP containing 50008, so originating lync is only able to send voice, but can't hear the other side.

What is the basis on which Lync makes this selection. i.e. why does it select the port 50014 in this case?

The 200 OK response from media gateway is 

v=0
o=- 0 0 IN IP4 172.21.145.152
s=session
c=IN IP4 172.21.145.152
t=0 0
m=audio 1654 RTP/AVP 9 8
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=sendrecv
a=maxptime:20

June 9th, 2015 12:06am

This is the way how Lync Supports the old ICE and new ICE Protokoll. You should use a certified Gateway.
Free Windows Admin Tool Kit Click here and download it now
June 11th, 2015 2:16pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics