Trimming

On 10/19/15 1:12 PM, K sipuser wrote:

- INVITE with codec1,codec2,codec3
- 183 received with codec2.
- Update *send* with codec4
- In early dialog state is this valid?

How is this different from (2)? The only difference I see is *received*
vs. *sent*. But every message received must have been sent.

Is (2) assuming the update is opposite direction to invite, while in (3)
the update is in the *same* direction as the update?

In any case, my comments on (2) also apply to (3).

Adi>>I mean in both the case2 and case3 , 183 is send reliably

OK. Then the UPDATE is ok.

 >>if SUT does not like codec4, can it reject with 4xx response in early
dialog state?

Yes.

 >>will that end the call?

No.

 >>can it continue with codec2 after sending a failure response?

Yes.

 > 4)INVITE with codec1,codec2,codec3200 OK received with codec2.--call
is connectedUpdate Received with codec4

- INVITE with codec1,codec2,codec3
- 200 OK received with codec2.
- call is connected
- Update Received with codec4

Yes, this is fine. But the recipient of the update can reject it and
continue the call with codec2.

The sender of the update needs to be prepared to receive either codec2
or codec4 until the response to the update is received. He should keep
sending codec2 until he knows whether codec4 has been accepted.

 > 5) if SDP offer has RR and RS=0.can answer be non-zero RR and RS?RR
in offer should be equal to RS in answer right?

I don't know what RR and RS mean in this context.
In general, in SDP we have RR and RS.

I still don't know what you mean by "RR" and "RS". I presume they are acronyms for something, but what?

        Thanks,
        Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to