Subject: [Sip] Codec Negotiation and renegotiataion

From: atul garg <[email-masked]>
Date: Wed, 13 Jul 2011 20:59:40 +0530 (IST)

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 ??
 
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 ??
 
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
  and what will be the d behaviour of A ....
   
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)
 
  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.
 
Regards
Atul

---

From: "Siddiqui, Noman" <[email-masked]>
Date: Wed, 13 Jul 2011 17:54:28 +0200

Hi Atul,

Please see inline.

Kind Regards,
Noman Siddiqui

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of atul garg
Sent: Wednesday, July 13, 2011 11:30 AM
To: [email-masked]
Subject: [Sip] Codec Negotiation and renegotiataion

Hello All,

    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
[Mohammed Noman Siddiqui] B would send 1, 3 in 200 OK

   if it is 1, 3, 5 then what will be the response to B ??
[Mohammed Noman Siddiqui] What do you mean by response to B. B is sending the response to A as above

    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
[Mohammed Noman Siddiqui] 2,3

    A -->  INVITE (SDP-> audio 1 2 3) --> B      ( B supports  4, 5,6)
    A <--  200 OK ( SDP -> what will be here ??)  <-- B
  and what will be the d behaviour of A ....
[Mohammed Noman Siddiqui] B would send 488 Not Acceptable here

4) Re-Negotiation -

( I guess the rtp will use codec 1)
[Mohammed Noman Siddiqui] Yes, RTP will use codec 1, however both sides should be able to dynamically switch the payload to either 2 and 3

  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)
[Mohammed Noman Siddiqui] Yes, dynamic payload switching based on the negotiated codecs list is permitted. Unfortunately, many devices do not support this and hence its better to do the re-negotiation.

Regards
Atul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jul 2011 13:01:43 -0400

> 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.

> 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.

> 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.

> ( 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 [email-masked] for questions on how to develop a SIP implementation.
> Use [email-masked] for new developments on the application of sip.
> Use [email-masked] for issues related to maintenance of the core SIP specifications.