Thanks Paul. Your answer is perfect. Regards, Yong
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Sunday, February 04, 2007 3:07 PM To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] RFC 3725 question: Re-INVITE with no SDP 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
