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)?
2) Does our current implementation on B make sense? Or what the controller
expects is correct?
3) If our implementation is correct, how can the controller re-connect B to
user C?
Thanks,
Yong
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
