See inline.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Sourav
Dhar Chaudhuri
Sent: Wednesday, November 05, 2014 2:24 AM
To: Brett Tate; [email protected]; [email protected]
Subject: Re: [Sip-implementors] Query regarding SDP negotiation
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.
[[Neel]]
Yes, there is no violation of RFC and call should continue. It is hard to say
why endpoint A is sending BYE.
[[Neel]]
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.
[[Neel]]
Endpoint A could have sent BYE for various reasons. Simply the caller might
have hung up the call. Or the Endpoint A needs the dynamic payload time same
for telephone-events. You can reach out the vendor of endpoint A.
[[Neel]]
Whether my above conclusion is correct?
Thanks
Sourav
On Wednesday, 5 November 2014 1:20 AM, Brett Tate <[email protected]> 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: [email protected] [mailto:sip-
> [email protected]] On Behalf Of Sourav Dhar
> Chaudhuri
> Sent: Tuesday, November 04, 2014 2:20 PM
> To: ankur bansal
> Cc: [email protected]
> 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
> <[email protected]> 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
> <[email protected]> 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
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
