Hi Brett & Ankur,
At first thanks to both of you for your prompt answer.
So after considering RFC 3264 ( importantly the section 8.3.2 mentioned in Ankur's latest reply) & RFC 4566, I came to this conclusion instead of sending A could have continue the call.
But my newer question is even by sending BYE for this flow A is not violating any RFC. Since from the booth RFCs mentioned above the expected behavior mentioned by Ankur is SHOULD way not in MUST. So A behavior may not the be best one but also not a violation of RFC.
Whether my above conclusion is correct?
Thanks
Sourav
On Wednesday, 5 November 2014 1:20 AM, Brett Tate <br...@broadsoft.com> wrote:
99 and 101 are for dynamic payloads. Notice that it is supported by both;
they just assigned different numbers to it.
See RFC 3264 and RFC 4566 for more details concerning the dynamic
payloads.
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sourav Dhar
Chaudhuri
Sent: Tuesday, November 04, 2014 2:20 PM
To: ankur bansal
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Query regarding SDP negotiation
Hi Ankur,
Thanks for your clarification. My question still remains.
In the offer from A does not have the support for payload no 101. So
why
you are saying it A SHOULD use it towards B instead of BYE. where only
B has
mentioned any payload support on 101. What is the basis of A should do
that
activity ? Is it best possible SDP negotiation in case not exact
matching ?
Moreover how will B sends the telephony event with payload 99. B has
not
mentioned it support for payload 99.
Thanks
Sourav
On Tuesday, 4 November 2014 9:48 PM, ankur bansal
<abh.an...@gmail.com> wrote:
Hi Saurav
I believe there is no issue due to rtpmap as its required only for
dynamic
payloads and not for static payloads .
Reason of UE A sending BYE could be mismatch in payload no for telephony
event .
A is sending 99 but B is sending 101 .So A finds this wrong and send BYE
But
UE Ashould not send BYE and accept this answer sending telephony events
with payload no 101 instead of 99 which is expected by UE B.
And UE B needs to send telephony events with payload no 99 towards UE A.
Hope this helps
Thanks & Regards
Ankur Bansal
On Tue, Nov 4, 2014 at 9:12 PM, Sourav Dhar Chaudhuri
<sourav_mi...@yahoo.co.in> wrote:
Hi,
I am observing a behavior SDP negotiation. In the Below Example just
After Media Negotiation. A is sending BYE without any media flow .
Please
refer the below call flow & my query.
A --------------------------- INVITE with SDP
-------------------------> B
########## SDP details in Offer ##############
v=0
o=- 1414764441 1414764441 IN IP4 172.29.62.182 s=Basic Session c=IN IP4
172.29.62.182
t=0 0
m=audio 37620 RTP/AVP 18 8 0 99 106 107
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=rtpmap:106 PCMU/8000
a=rtpmap:107 PCMA/8000
a=ptime:20
A <------------------------- 100 Trying
-------------------------------------- B
A <------------------------ 180 Ringing
(unreliable)------------------------------------- B
A <------------------------ 200 OK with SDP
------------------------------ B
########## SDP details in Answer ################
v=0
o=0000000000 37448557 1 IN IP4 172.29.62.11
s=-
c=IN IP4 172.29.62.11
t=0 0
m=audio 53378 RTP/AVP 8 101
a=sendrecv
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
A -------------------------- ACK
-------------------------------------------> B A
-------------------------- BYE
------------------------------------------> B
the call is getting disconnected without any media transfer.
I can see there are six codecs [ 18 8 0 99 106 107 ] with attribute
for only for
three [ 99 106 107 ] in SDP offer. Those three [ 99 106 107 ] only
having
rtpmap details.
But in SDP answer two codec [ 8 101 ] with attribute for only [ 101 ].
The
rtpmap is also for only [ 101 ].
So is the A is behaving correctly ? Whether there is failure in SDP
negotiation? If yes then why?
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
