Yong Xin wrote:
> Hi,
>
> In RFC3725 (section 11), it suggests the SIP UA should support re-INVITE
> with no SDP.
> However, it does not clear describe what offer should be included by UA in
> the 200 ok
> response.
>
> See following call flow:
>
>
> A Controller B C
> |(1) INVITE no SDP | | |
> |<------------------| | |
> |(2) 200 offer1 | | |
> |------------------>| | |
> | |(3) INVITE offer1 | |
> | |------------------>| |
> | |(4) 200 OK answer1 | |
> | |<------------------| |
> | |(5) ACK | |
> | |------------------>| |
> |(6) ACK answer1 | | |
> |<------------------| | |
> |(7) RTP | | |
> |.......................................| |
> |(8) BYE | | |
> |------------------>| | |
> |(9) 200 OK | | |
> |<------------------| | |
> |(10) re-INV no SDP | |
> |------------------>| |
> |(11) 200 offer2 | |
> |<------------------| |
> |(12) INV offer2' | |
> |----------------------------------->|
> |(13) 200 answer2' |
> |<-----------------------------------|
> |(14) ACK |
> |----------------------------------->|
> |(15) ACK answer2 | |
> |------------------>| |
> |(16) RTP |
> |................|
>
> User B is an automata (media server) which our implementation is concerned.
> With our current implementation, whenever B receives a re-INV (no sdp) from
> Controller, B will return the same sdp as it sent last time. In this call
> flow, you would see the "offer2" in message (11) is exactly the same as the
> "answer1" in message (4). However, the Controller expects to see B offers
> all media formats that it can support in (11), not only the single media
> format that was negotiated for user A in (4), because the user C may support
> a different media format than user A.
>
> My questions are:
>
> 1) Could anyone tell me which RFC specified the UA behaviour when receiving
> re-INVITE (with no SDP)?
AFAIK there is none that explicitly deals with this.
> 2) Does our current implementation on B make sense? Or what the controller
> expects is correct?
What you are doing is *valid*. But what the controller expects is
"better", because it facilitates callflows exactly like this one.
Returning what you used previously will generally work ok if you end up
talking to the same UA again. But you have no way to know that is what
will be happening. So you should offer everything you are wiling and
able to support at the time, which will facilitate operation with
whoever/whatever you end up talking with.
The only real limitation in the reinvite case is that you *should*
include something in common with what you had been doing before, in
order to ensure that you can still talk with the same UA you had been.
But of course if you offer everything you are willing and able to do,
and if you are willing and able to do what you had been doing, then this
will happen by default.
> 3) If our implementation is correct, how can the controller re-connect B to
> user C?
As you are currently doing things, you will only be able to talk to C
using codecs you had in common with A. Its quite possible that you could
have codecs in common with both A and C, even though A and C have no
codecs in common with one another. So your current approach is far from
ideal.
Paul
> Thanks,
>
> Yong
>
>
>
>
>
>
> _______________________________________________
> 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
