>What is the behavior of the receiver if it receives offer with >different "session id" in >re-INVITE or UPDATE?
Take down the call as REINVITE o-line with a new session id identifies a session that does not exist at UA. [Kamal] Taking down the existing call may not be a good idea, one can reject the request that contains changed SDP session-id. Instead the re-INVITE or UPDATE should be rejected. Kamal Cisco, Bangalore India -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harsha. R Sent: Tuesday, September 30, 2008 4:06 PM To: Vikram Chhibber Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Few offer/answer queries Vikram, Session id is kept constant across offers/answers sent by UAC/UAS. Only Session version is incremented for every new offer/answer sent by UAC/UAS. The reason UA *MUST NOT* change session id can probably be inferred from SDP RFC 4566, section 5.2 <sess-id> is a numeric string such that the tuple of <username>, <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a globally unique identifier for the session. Therefore by changing the session id, you are changing the identifier for the session for either a UAC/UAS To answer your specific questions. >What is the behavior of the receiver if it receives offer with >different "session id" in >re-INVITE or UPDATE? Take down the call as REINVITE o-line with a new session id identifies a session that does not exist at UA. >Also, what should be the behavior of the receiver if it receives offer >with same "session id" as previous but with version incremented more >than one? IMO, a liberal implementation *SHOULD* allow this offer/answer to proceed. For me, this bears similarity to the case when CSeq is incremented more than 1 for a subsequent request from a UAC. >b) We emphasize that UAS should send back its full capability offer in >response to offer-less re-INVITE. Does that also have "SDP session >resetting" effect in the sense that the answer SDP MAY not have same "o" >line session-id as sent by remote previously? This scenario comes when >you are trying to negotiate media-session with another entity within an >established SIP dialog say network side call-transfer. In this case of forced SDP offer, UAS must use the same session id in the offer it sends, as it sent in a previous answer(in either 18X response/200 OK INVITE), and increment the session version by 1. Regards Harsha 2008/9/30 Vikram Chhibber <[EMAIL PROTECTED]> > Hi All, > > > > I have few queries on RFC 3264: An Offer/Answer Model with the Session > Description Protocol (SDP): > > > > 8 Modifying the Session > > .... > > When issuing an offer that modifies the session, > > the "o=" line of the new SDP MUST be identical to that in the > > previous SDP, except that the version in the origin field MUST > > increment by one from the previous SDP. > > > > The aforementioned statement defines the "o" line creation in the > offer by the sender. > > > > a) Does this also mean that the receiver must always expect same > "session id" in all the subsequent offers after initial offer/answer? > What is the behavior of the receiver if it receives offer with different "session id" > in > re-INVITE or UPDATE? Also, what should be the behavior of the receiver > if it receives offer with same "session id" as previous but with > version incremented more than one? > > Are the above scenarios "legal" for UA or should it treat these > normally and continue by following philosophy of being strict while > sending and lenient while receiving? > > > > b) We emphasize that UAS should send back its full capability offer in > response to offer-less re-INVITE. Does that also have "SDP session > resetting" effect in the sense that the answer SDP MAY not have same "o" > line session-id as sent by remote previously? This scenario comes when > you are trying to negotiate media-session with another entity within > an established SIP dialog say network side call-transfer. > > > > Thanks, > > ~Vikram > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Regards Harsha _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
