nal 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
>
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
PM
> To: Harsha. R
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Few offer/answer queries
>
> Thanks Harsha, this is what I was also expecting. I just
> wanted some formal description on this and I found it in
> http://www.ietf.org/intern
Thanks Harsha, this is what I was also expecting. I just wanted some formal
description on this and I found it in
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
o In the o-line, only the version number may change, and if it
changes it must increment by one
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
is a numeric string such that the tup
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
