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
