On 7/14/11 5:34 AM, atul garg wrote:
> Thanks Paul,
>
> Your inputs made it almost clear to me the ebhaviour of codec
> negotiation. However I have one more interesting question now(came after
> discussion with some guy), like is it possible to have two different
> codecs being used in single RTP session at the same time.
Yes, it is possible to use two at the same time.
The classic example is when one of the is telephone-event, which is used
in conjunction with another codec.
But certainly it is technically valid to switch among all the codecs
that are mentioned in both the offer and the answer. (I am however not
an expert at codec implementation. I realize there may be technical
issues with switching among codecs in this way. But that isn't
considered in the offer/answer rules.)
> I mean A
> initiates the call to B with SDp codec offrs( 1, 2, 3) it means that A's
> priority is 1 however it supports 2 and 3 also. Now b also supports (1
> ,2 ,3) but its priority is to have 2 (may be some bandwidth reason or
> quality issue). Now what will be the B's response and further behavior-
>
> Will B send ( 2, 1, 3) or it shall send (1 ,2, 3) -
I guess you are asking what the answer will contain, not what is
actually transmitted in the media stream?
AFAIK B *SHOULD* honor A's priorities. But that means it might not.
So in reality it could do whatever it wants.
> If ( 2, 1 , 3)-
>
> a) Will this be assumed that A and B are agreed upon 2 OR
No. They are agreed on 2,1,3
> b) A will send update with SDP( 2, 1, 3) OR
It could, but isn't obligated to.
> c) A will Drop this call and send the Invite again with ( 2, 1 3) OR
It could, but that seems like a very bad idea
> d) As they have two streams one is for receiving and other for
> sending(ie logical channels i guess)- and A shall send the RTP using
> codec 2( as B is supposed to receive on this) while B shall send using
> codec 1( as A's priority was 1 and it is supposed to receive on 1)
It could, if its capable of doing so.
You are discussing things that are *not specified* by the standards.
Anything not forbidden is permitted.
Thanks,
Paul
> Regards
> Atul
>
>
> --- On *Wed, 13/7/11, Paul Kyzivat /<pkyzi...@alum.mit.edu>/* wrote:
>
>
> From: Paul Kyzivat <pkyzi...@alum.mit.edu>
> Subject: Re: [Sip] Codec Negotiation and renegotiataion
> To: s...@ietf.org
> Date: Wednesday, 13 July, 2011, 10:31 PM
>
> On 7/13/11 11:29 AM, atul garg wrote:
> > Hello All,
> > I have very basic question regarding the codec negotiation in SIP, I
> > will try to summarize my queries below -
> > 1) If A is initiating the call and sending the supported codec
> list say
> > (1,2,3)
> > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 1 , 3, 5)
> > A <-- 200 OK ( SDP -> what will be here 1, 2 ,3 OR 1, 3, 5) <-- B
> > if it is 1, 3, 5 then what will be the response to B ??
>
> The answer could include 1; 1,3; 1,3,5; or I suppose 1,5; 3,5.
>
> A doesn't "respond" to B.
> If the answer contains both 1,3 then A could use either 1, 3, or
> both when sending to B, and B can use either 1, 3, or both when
> sending to A.
> So if B only wants to use one codec it would be well advised to only
> mention one in the answer.
>
> If B mentioned codec 5, it isn't really useful immediately. Its just
> an FYI for A. It could be treated as a hint, in case A does support
> 5 and just didn't mention it.
>
> > 2) If A is initiating the call and sending the supported codec
> list say
> > (1,2,3)
> > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 2 , 3, 5)
> > A <-- 200 OK ( SDP -> what will be here 2 , 3 OR 2 , 3, 5) <-- B
> > if it is 2 , 3 then what will be the response to B ??
> > if it is 2 , 3, 5 then what will be the response to B ??
>
> This isn't much different from (1).
> B could answer with any of the things you say.
>
> > 3) If A is initiating the call and sending the supported codec
> list say
> > (1,2,3)
> > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 4, 5,6)
> > A <-- 200 OK ( SDP -> what will be here ??) <-- B
>
> Typically B would respond with 488.
> If it wants, it could respond 200 and refuse the media stream (port 0).
> That is probably not a good idea unless it has further plans - e.g.
> to make another offer of some sort.
>
> > and what will be the d behaviour of A ....
>
> If the response is 488, A gives up.
> If response is 200 with refused media, it might want to wait and see
> what happens next. Or else it might as well send a BYE.
>
> > 4) Re-Negotiation -
> > If A is initiating the call and sending the supported codec list
> say (1,2,3)
> > A --> INVITE (SDP-> audio 1 2 3) --> B ( B supports 1 , 2, 3)
> > A <-- 200 OK ( SDP audio1, 2 ,3 <-- B
> > A --> ACK --> B
> > ( I guess the rtp will use codec 1)
>
> rtp could be 1, 2, 3, or a combination.
>
> > Now during the call say A wants to change the codec to 2, will it
> send
> > the re-invite or SDP session has some provision for it( I just
> want to
> > confirm, is it possible to change the codec without sending any
> SIP message)
> > PS: I know i have made a lengthy mail, but it is very much
> required for
> > me to understand some network behaviour and implementation.
>
> If 1,2,3 negotiated, it can just start using 2.
>
> But I think this will break a number of implementations that make
> unjustified assumptions. I know there are big vendors with products
> that can only support one codec and must renegotiate to switch, and
> assume the first one in the answer is the one to be used.
>
> So you would be well advised to send a new offer with just 2 if that
> is the one you want to use.
>
> Thanks,
> Paul
>
> > Regards
> > Atul
> >
> >
> >
> > _______________________________________________
> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> > This list is essentially closed and only used for finishing old
> business.
> > Use sip-implement...@cs.columbia.edu
> </mc/compose?to=sip-implement...@cs.columbia.edu> for questions on
> how to develop a SIP implementation.
> > Use dispa...@ietf.org </mc/compose?to=dispa...@ietf.org> for new
> developments on the application of sip.
> > Use sipc...@ietf.org </mc/compose?to=sipc...@ietf.org> for issues
> related to maintenance of the core SIP specifications.
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old
> business.
> Use sip-implement...@cs.columbia.edu
> </mc/compose?to=sip-implement...@cs.columbia.edu> for questions on
> how to develop a SIP implementation.
> Use dispa...@ietf.org </mc/compose?to=dispa...@ietf.org> for new
> developments on the application of sip.
> Use sipc...@ietf.org </mc/compose?to=sipc...@ietf.org> for issues
> related to maintenance of the core SIP specifications.
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
