Jagan Mohan wrote:
> Hi,
>
> Consider the following call flow:
>
> UAC --------------------- UAS
>
> INVITE ----------->
> 100 Trying <-----------
>
> 183 Progress <-----------
> PRACK ------------>
> 200 PRACK <------------
>
> UPDATE ------------>
> 200 UPDATE <-----------
>
> 200 OK <-----------
>
> Consider the case where the INVITE request has multiple 'm=' lines in the
> above call flow.
You aren't very clear about where the offers and answers are.
I will assume that the invite has offer 1, the 183 has answer 1, the
update has offer 2, and the 200 for the update has answer 2. Right?
> Now, when an UDPATE request is sent with a codec in the SDP which is not
> present in the initial INVITE request, how should the UAS respond in the 200
> OK to the INVITE?
>
> For example, INVITE request has 2 'm=' lines with G.711 and G.729 codecs.
> And UPDATE request has a single "m=" line with only G.723 codec.
> 1) Is it ok to have only one "m=" line in the UDPATE request here?
> 2) If yes, how would the UAS fill up the "m=" lines in the 200 OK response
> to the INVITE request?
The above makes little sense. Can you provide the actual messages?
Do you really mean the invite has two m-lines? Or one m-line with two
codecs? (Which would be far more normal.)
If the invite actually has two m-lines, then the update must have at
least two m-lines. If the update had only one, then it would be invalid.
If the invite had one m-line with two codecs, then the update may also
contain only one m-line. It legal, though not recommended, for the
second offer to include a new codec without including one agreed to
previously. In that case, the answerer has some choices:
- return a 200 to the update, with an answer that accepts the new codec
- return a 200 to the update, with an answer that rejects the m-line
by setting the port to zero. Then you will have a session with no
media streams
- reject the UPDATE, which will leave the (early) session in the state
it was following the 183.
In any case, when using reliable provisionals and update this way, it is
best for the 200 to the INVITE to contain no answer at all.
Paul
> Thanks,
> Jagan
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
