...@gmail.com
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 conclusi
If g. R
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: ankur bansal
Sent: Wednesday, November 5, ( $#!14 10:54 PM
To: Paul Kyzivat
Cc: sip-implementors
Subject: Re: [Sip-implementors] Query regarding SDP negotiation
Saurav
We always try to complete call
Saurav
We always try to complete call somehow as providing reliable service to
user is utmost important and i have seen solutions voilating standards in
actual deployments to provide services to end user.
And luckily in our scenario standard is recommending the acceptance of diff
payloads to make c
On 11/5/14 7:05 AM, Brett Tate wrote:
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 violatio
> 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
-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 SD
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
sage-
> 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: R
Please refer rfc 3264 section 8.3.2
On Nov 5, 2014 12:50 AM, "Sourav Dhar Chaudhuri"
wrote:
> 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 ins
to: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,
>
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
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 A* should no
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 Of
13 matches
Mail list logo
