Subject: [Sipping] I-D ACTION:draft-ietf-sipping-sip-offeranswer-01.txt

From: [email-masked]
Date: Tue, 29 May 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: SIP (Session Initiation Protocol) Usage of Offer/Answer Model
	Author(s)	: T. Sawada, P. Kyzivat
	Filename	: draft-ietf-sipping-sip-offeranswer-01.txt
	Pages		: 21
	Date		: 2007-5-29
	
SIP utilizes offer/answer model to establish and update multimedia 
       sessions. The descriptions on how to use offer/answer in SIP are 
       dispersed in the multiple RFCs. This document summarizes all the 
       current usage of offer/answer model in SIP communication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sipping-sip-offeranswer-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-sip-offeranswer-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Byron Campen <[email-masked]>
Date: Tue, 5 Jun 2007 08:52:46 -0500

No problem. A few responses inline:

> Byron,
>
> Thank you for the careful review and thoughtful suggestions. I've  
> responded below based on my own opinions. I haven't consulted with  
> Takuya, so I look forward to his comments as well.
>
> Is it ok for us to post this to the sipping list?
>
> 	Thanks,
> 	Paul
>
> Byron Campen wrote:
>>   Here are my notes from my first pass. There are a handful of  
>> technical issues, the rest are editorial in nature.
>> *Technical/clarifications:*
>> Section 2.1:
>> "All the session descriptions in the
>>        unreliable responses to the INVITE request must be  
>> identical to the
>>        answer which is included in the reliable response."
>>       I just know someone is going to selectively misunderstand  
>> this bit and assert that they don't need to handle the case where  
>> they get multiple different SDPs on a forked call, and I am  
>> probably going to have to argue with them someday.
>
> We wouldn't want that to happen - that is why this is being written.
>
> It is covered, in second paragraph of section 1.1. Is this not  
> explicit enough for you? Would the following be better?
>
>        Note that an offer/answer exchange initiated by an INVITE  
> request
>        must follow exactly one of the patterns 1, 2, 3, 4. When an
>        INVITE results (via forking) in the creation of more than one
>        dialog, a distinct offer/answer exchange is carried out
>        independently within each dialog, and each may use a different
>        pattern.
>

	Believe me, I do not like repeating myself any more than you (or any  
of the rest of us), but experience has shown that implementors are  
very good at missing details like this, especially if these details  
keep said implementors from making simplifying assumptions. And then,  
arguments ensue at SIPit, and I eventually have to throw these  
implementors at Robert because they don't believe me (they are _very_  
good at ignoring text unless Robert is present, apparently). Maybe an  
indented NOTE: section would work here, something to the tune of

	"NOTE: This restriction applies to a single offer/answer exchange.  
Parallel offer/answer 	exchanges (caused by forking) will obviously  
not send the same answer. UAs are expected to deal with this."

>> Section 3.1:
>> "When offer2 is in a PRACK request, that is, when a PRACK request to
>>        acknowledge the reliable provisional response with an  
>> answer to the
>>        offer in the INVITE request contains a session description,  
>> UA A
>>        knows it is an offer."
>>       I am not sure this scenario can arise without some sort of  
>> misbehavior.
>
> I certainly *thought* there was a case for this, but so far I have  
> not been able to reconstruct it. Maybe Takuya remembers a case for  
> this.
>
>> A has to send an answer in a 1xx-rel at some point for B to send  
>> an offer in a PRACK.  So, let's say A sends an answer in a 1xx-rel  
>> (not
>> pictured, happens before the beginning of the diagram), and then  
>> immediately issues a new offer (offer1, using UPDATE).
>
> That does seem to be the only scenario for setting up an offer in a  
> PRACK.
>
>  If B gets the
>> UPDATE first, we have a glare condition, and B will reject (since  
>> B didn't get the 1xx-rel answer yet).
>
> Yup.
>
>> If B gets the 1xx-rel first, it will send offer2, and when the  
>> UPDATE shows up, we will once again have a glare condition, with B  
>> rejecting the UPDATE.
>
> Well, its *possible* (though implausible) that B receives the 1xx  
> rel first but decides to answer the UPDATE first, and so responds  
> to it with an answer. Then, when it gets around to sending the  
> PRACK it realizes it has something to offer that wasn't included in  
> the response to the UPDATE.
>
> (The following illustrates the case)
>
>         A                  B
>         |INVITE(offer0)    |
>         |<-----------------|
>         |1xxRel(answer0)   |
>         |----------------->|
>         |UPDATE(offer1)    |
>         |----------------->|
>         |          2xx UPD |
>         |         (answer1)|
>         |<------\  /-------|
>         |        \/  PRACK |
>         |        /\  offer2|
>         |<------/  \-------|
>
> This seems implausible primarily because of answering the UPDATE  
> for sending the PRACK. But it might be possible in some  
> implementations due to parallelism, or conceivably it could even be  
> intentional.
>
> I guess the real question is what recommendation to make to avoid  
> the problems of this case. The situation could be headed off  
> earlier by always PRACKing a 1xxRel before responding to a request  
> that is received after it. Its tricky to specify how much  
> serialization is required without specifying too much. The current  
> recommendation only specifies a remedy after the fact when it can  
> be known that there is a problem if something isn't done.
>

	Yeah, I had thought of this case, but was lumping it in with  
"misbehavior". But, it is a subtle error, and you're right that we  
can't specify it away.

>
>> Section 3.2:
>> "To avoid glare condition for offer2 in the response, UA A is
>>        recommended not to send a new offer if it has sent a (re) 
>> INVITE
>>        request without session description and has not received  
>> the reliable
>>        response which includes the offer."
>> It seems that here we are recommending that A wait until either  
>> the end of the INVITE transaction, or the completion of an offer- 
>> answer exchange within that transaction, whichever comes first.  
>> (Since we are waiting at least until we get an offer, and then we  
>> have to answer anyway before issuing the offer.)
>
> If I follow, you are suggesting a different wording which is  
> functionally equivalent. But its not entirely clear its  
> functionally equivalent.
>
> Both remedies listed are kind of hard to follow. In particular, its  
> not entirely clear this is describing two subcases - when Offer2 is  
> in a request, and when it is in a response. The following is an  
> attempt to clarify:
>
>   When offer2 is in a PRACK request (only possible if offer1 is in
>   an UPDATE request), the PRACK may be accepted with 200 or may
>   be rejected with a 491 response. A 491 is valid to satisfy the
>   offer/answer model but it may delay the completion of the reliable
>   response transfer mechanism or, in worst case, may result in the
>   failure to complete the SIP transaction because there is no clear
>   retry rule when a PRACK request is rejected with a 491 response. To
>   avoid this glare condition, UA A should not send an offer if it has
>   already sent a reliable provisional response containing an answer to
>   a previous offer and has not yet received the corresponding PRACK.
>
>   To avoid a glare condition involving an offer in a response, when
>   UA A has sent a (re)INVITE request without an offer, it should not
>   send an offer until it has received an offer in a reliable response
>   to the (re)INVITE, and sent an answer to that offer.
>

	I like this text better.
	
>> Section 4.2.3:
>> "For each accepted m-line in the answer, there must be at least
>>        one media format in common with those in the request."
>> Do we mean "at least one media format in common with the  
>> corresponding m-line of the offer"? (This is not immediately  
>> obvious to me, looking at the RFC)
>
> IMO that is exactly what is intended here, and what is logically  
> necessary. If the answer can have no media formats in common then  
> it should be rejected with a zero port.
>
> So I think we should adopt your wording.
>
>> Section 5.2:
>> "When a re-INVITE transaction fails, the dialog remains with the
>>        session bound to it."
>>       This is true most of the time, but some responses will kill  
>> the session, or even the whole dialog. Suggest putting in "...,  
>> often the dialog remains...", maybe a reference to dialogusage.
>
> Yes, I agree.
>
>> *Editorial (syntax/grammar):*
>> Section 1.1:
>> "Pattern 2 and pattern 4 can occur
>>        only when the INVITE request does not include an offer.  
>> 'The first
>>        reliable non-failure message' must have..."
>> stray single quotes?
>
> Looks that way to me.
>
>> Section 4.1:
>> "Some UAs may not have an understanding of what it is interested in
>>        doing at a particular time."
>>       Mixing singular with plural here. Suggest "A given UA may  
>> not..." or "...of what they are interested in..."
>
> Yep.
>
>> continuing with a couple of nits on the same paragraph...
>>              "(E.g. a gateway to a different protocol.)
>>        In this case the UA could delegate the decision to the  
>> other protocol,
>>        if the situation can be represented."
>> I don't mind parenthetical remarks (in fact, I use them  
>> liberally), but referring back to the contents of a parenthetical  
>> remark outside of the parenthesis is generally a no-no. Suggest  
>> "In the case where the UA is a gateway to a different protocol,  
>> the decision could be delegated to the other protocol."
>  >       "Or it can make some assumptions.
>>        This may result in a limitation in what works through the  
>> gateway."
>> I suggest combining these two sentences.
>> "A gateway UA may also make assumptions about what it is  
>> interested in, but this  may limit what works through the gateway."
>
>
> I appreciate your point, but I was trying to be more general, while  
> illustrating with a real case. How about:
>
>   Some types of UA may not have direct knowledge of what they are
>   interested in doing at a particular time. If it is an intermediary
>   it may be able to delegate the decision. In the worst case it may
>   apply a default, such as assuming it wants to use all of its
>   capabilities.
>

	I like this text.

>
>> Section 4.2.2:
>> "It there is a possibility that the user of the device
>>             may wish to change what is offered before answering  
>> the call,
>>             then special care should be taken."
>> Was probably intended to read "If there is a possibility...".
>
> Yes.
>
>> Also, the "...*may* wish to change..." is redundant, suggest  
>> "...*will* wish to change...".
>
> Yes again.
>
>> *NITS:*
>> Section 1:
>> "In RFC 3264 [3], which defines
>>        the offer/answer model, which SIP message should convey an  
>> offer or
>>        an answer is not defined."
>> tad awkward (which...which), maybe change to
>> "RFC 3264 [3] defines the offer/answer model, but does not specify  
>> which SIP messages should convey the offer or answer."
>
> sounds good to me.
>
>> Section 1:
>> ".. described in the standard track RFCs.."
>> should be
>> ".. described in the standards-track RFCs.."
>> Section 1.1:
>> "Note that an offer/answer exchange initiated by an INVITE request
>>        must follow exactly one of the patterns 1, 2, 3, 4. Only  
>> one of them,
>>        one for each dialog if multiple dialogs are created, must  
>> occur in an
>>        INVITE 3-way handshake process."
>>       Second sentence seems redundant, although the point that  
>> multiple parallel, distinct offer-answer exchanges might occur is  
>> valuable. Maybe have the second sentence read like "When a dialog- 
>> establishing INVITE causes multiple offer/answer exchanges due to  
>> forking, these offer/answer exchanges may use different patterns,  
>> since they are distinct."
>
> Covered earlier. I didn't follow your wording but I did borrow from  
> it.
>
>> Section 1.1:
>> "'Early' column shows the ability to be used to modify... "
>> awkward, perhaps remove the "to be used".
>
> How about: "The 'Early' column indicates which patterns may be used  
> to modify the established session in an early dialog."
>
> Also, we should put "The " in front of 'Ini' and 'Est'.
>
>> Section 1.2:
>> "...with an offer which it can not
>>        accept..."
>> A tad awkward, and several occurances, suggest "...with an  
>> unacceptable offer..." as an alternative.
>
> Sounds good.
>
>> Section 3.1:
>> "Note that if UA A does not send an INVITE request without session
>>        description if it has sent the offer which has not yet  
>> received the
>>        answer to it, this case never happens."
>>       Awkward, I suggest
>> "Note that this case only occurs when UA A, while waiting for an  
>> answer, sends an INVITE request without session description."
>
> Good again.
>
>> Section 3.2:
>> "To
>>        avoid this glare condition, UA is recommended not to send  
>> an offer,
>>        which currently must be in an UPDATE request, if it has  
>> generated the
>>        reliable provisional response with the answer to the offer  
>> in the
>>        INVITE request which is not acknowledged with a PRACK  
>> request."
>> Awkward, I suggest
>> "This glare condition can be avoided if the UA waits until the  
>> receipt of the PRACK to its answer-carrying 1xx-rel before sending  
>> another offer, which currently must be sent using an UPDATE request."
>
> I proposed something different above before I got to this. Does  
> that work for you?
>

	Yeah, that looks good.

>> Section 4.3:
>> "However, its local
>>        desired state will now be either "sendonly" or "inactive"  
>> according
>>        to *how* it desires to send Music on Hold."
>>       Suggest changing "...according to *how* it desires..." to  
>> "...according to *whether* it desires..."?
>
> Yeah, that is better.
>
> 	Thanks,
> 	Paul
>

I'll probably give this a second pass in the near future, but I  
imagine I won't find much more than nits. All in all, this does an  
excellent job of motivating the material.

Best regards,
Byron Campen

>>> *From: [email-masked] <mailto:[email-masked]>
>>> *Date: *May 29, 2007 2:50:02 PM CDT
>>> *To: [email-masked] <mailto:[email-masked]>
>>> *Cc: [email-masked] <mailto:[email-masked]>
>>> *Subject: **[Sipping] I-D ACTION:draft-ietf-sipping-sip- 
>>> offeranswer-01.txt *
>>>
>>> A New Internet-Draft is available from the on-line Internet- 
>>> Drafts directories.
>>> SIP utilizes offer/answer model to establish and update  
>>> multimedia        sessions. The descriptions on how to use offer/ 
>>> answer in SIP are        dispersed in the multiple RFCs. This  
>>> document summarizes all the        current usage of offer/answer  
>>> model in SIP communication.
>>>
>>> To remove yourself from the I-D Announcement list, send a message  
>>> to [email-masked] <mailto:i-d-announce- 
>>> [email-masked]> with the word unsubscribe in the body of the  
>>> message. You can also visit https://www1.ietf.org/mailman/ 
>>> listinfo/I-D-announce to change your subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with  
>>> the username "anonymous" and a password of your e-mail address.  
>>> After logging in, type "cd internet-drafts" and then "get draft- 
>>> ietf-sipping-sip-offeranswer-01.txt".
>>>
>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ 
>>> 1shadow-sites.txt
>>>
>>> [email-masked] <mailto:[email-masked]>.
>>> In the body type:
>>> Content-Type: text/plain
>>> Content-ID: <[email-masked] <mailto: 
>>> [email-masked]>>
>>>
>>> Use [email-masked] <mailto:sip- 
>>> [email-masked]> for questions on current sip
>>> Use [email-masked] <mailto:[email-masked]> for new developments of  
>>> core SIP

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 11 Jun 2007 20:43:49 +0900

Byron,

Thank you for the review and comments.
I would like to incorporate them into the new version.

I added the responses inline [TS].

>>>        unreliable responses to the INVITE request must be  identical to 
>>> the
>>>       I just know someone is going to selectively misunderstand  this 
>>> bit and assert that they don't need to handle the case where  they get 
>>> multiple different SDPs on a forked call, and I am  probably going to 
>>> have to argue with them someday.
>>
>> It is covered, in second paragraph of section 1.1. Is this not  explicit 
>> enough for you? Would the following be better?
>>
>>        Note that an offer/answer exchange initiated by an INVITE  request
> Believe me, I do not like repeating myself any more than you (or any  of 
> the rest of us), but experience has shown that implementors are  very good 
> at missing details like this, especially if these details  keep said 
> implementors from making simplifying assumptions. And then,  arguments 
> ensue at SIPit, and I eventually have to throw these  implementors at 
> Robert because they don't believe me (they are _very_  good at ignoring 
> text unless Robert is present, apparently). Maybe an  indented NOTE: 
> section would work here, something to the tune of
>
> Parallel offer/answer exchanges (caused by forking) will obviously  not 
> send the same answer. UAs are expected to deal with this."
>
[TS]
This seems to be obvious to me. Even so, to make it clearer to everyone,
adding this kind of note is fine, no problem.

BTW, UAs always "send" the same answer. UAs may receive different
answers when it deals multiple dialogs caused by forking. Then;

  NOTE: This "preview" session description rule
  applies to a single offer/answer exchange. In
  parallel offer/answer exchanges (caused by
  forking) UA may obviously receive the different
  "preview" of answer in each dialog. UAs are
  expected to deal with this.

------------

>>>  acknowledge the reliable provisional response with an answer to the
>>>  offer in the INVITE request contains a session description,  UA A
>>>  knows it is an offer."
>> I certainly *thought* there was a case for this, but so far I have  not 
>> been able to reconstruct it. Maybe Takuya remembers a case for  this.
>>
>>> A has to send an answer in a 1xx-rel at some point for B to send  an 
>>> offer in a PRACK.  So, let's say A sends an answer in a 1xx-rel  (not
>>> UPDATE first, we have a glare condition, and B will reject (since  B 
>>> didn't get the 1xx-rel answer yet).
>>
>> Yup.
>>
>>> If B gets the 1xx-rel first, it will send offer2, and when the  UPDATE 
>>> shows up, we will once again have a glare condition, with B  rejecting 
>>> the UPDATE.
>>
>> Well, its *possible* (though implausible) that B receives the 1xx  rel 
>> first but decides to answer the UPDATE first, and so responds  to it with 
>> an answer. Then, when it gets around to sending the  PRACK it realizes it 
>> has something to offer that wasn't included in  the response to the 
>> UPDATE.
>>
>> This seems implausible primarily because of answering the UPDATE  for 
>> sending the PRACK. But it might be possible in some  implementations due 
>> to parallelism, or conceivably it could even be  intentional.
>>
>> I guess the real question is what recommendation to make to avoid  the 
>> problems of this case. The situation could be headed off  earlier by 
>> always PRACKing a 1xxRel before responding to a request  that is received 
>> after it. Its tricky to specify how much  serialization is required 
>> without specifying too much. The current  recommendation only specifies a 
>> remedy after the fact when it can  be known that there is a problem if 
>> something isn't done.
>>
>
> "misbehavior". But, it is a subtle error, and you're right that we  can't 
> specify it away.
>
[TS]
I hope we reach the same consensus.
I think, in the current offer/answer cases, the case that Paul descriped 
above
can be the only case now.
Anyway, it is very rare case in a real world.

-------
>>>  recommended not to send a new offer if it has sent a (re) INVITE
>>>  request without session description and has not received the reliable
>>> It seems that here we are recommending that A wait until either  the end 
>>> of the INVITE transaction, or the completion of an offer- answer 
>>> exchange within that transaction, whichever comes first.  (Since we are 
>>> waiting at least until we get an offer, and then we  have to answer 
>>> anyway before issuing the offer.)
>>
>> functionally equivalent. But its not entirely clear its  functionally 
>> equivalent.
>>
>> Both remedies listed are kind of hard to follow. In particular, its  not 
>> entirely clear this is describing two subcases - when Offer2 is  in a 
>> request, and when it is in a response. The following is an  attempt to 
>> clarify:
>>
[TS]
Yes, I will change the text as above.

------------
>>> Do we mean "at least one media format in common with the  corresponding 
>>> m-line of the offer"? (This is not immediately  obvious to me, looking 
>>> at the RFC)
>>
>> necessary. If the answer can have no media formats in common then  it 
>> should be rejected with a zero port.
>>
[TS]
OK.

----

>>>  This is true most of the time, but some responses will kill  the 
>>> session, or even the whole dialog. Suggest putting in "...,  often the 
>>> dialog remains...", maybe a reference to dialogusage.
>>
>> Yes, I agree.
>>
[TS]
OK.
Paul, do we need the reference to dialogue usage draft?

----

>>> *Editorial (syntax/grammar):*

Thank you for pointing out.
Basically I will update the text as you pointed here.

>>>  only when the INVITE request does not include an offer.  'The first 

[TS]
'The firsr reliable non-failure message' is the expression from
RFC 3261. That is why I use single quatation here.

>>> Mixing singular with plural here. Suggest "A given UA may  not..." or 
>>> "...of what they are interested in..."
>>
>> Yep.
>>
>>>  In this case the UA could delegate the decision to the other protocol,
>>> I don't mind parenthetical remarks (in fact, I use them  liberally), but 
>>> referring back to the contents of a parenthetical  remark outside of the 
>>> parenthesis is generally a no-no. Suggest  "In the case where the UA is 
>>> a gateway to a different protocol,  the decision could be delegated to 
>>> the other protocol."
>>>  This may result in a limitation in what works through the gateway."
>>> "A gateway UA may also make assumptions about what it is  interested in, 
>>> but this  may limit what works through the gateway."
>>
>>
>>>  may wish to change what is offered before answering the call,
>>> Also, the "...*may* wish to change..." is redundant, suggest  "...*will* 
>>> wish to change...".
>>
>> Yes again.
>>
>>> *NITS:*
>>> Section 1:
>>>  the offer/answer model, which SIP message should convey an offer or
>>>  must follow exactly one of the patterns 1, 2, 3, 4. Only one of them,
>>>  one for each dialog if multiple dialogs are created, must occur in an
>>>  Second sentence seems redundant, although the point that  multiple 
>>> parallel, distinct offer-answer exchanges might occur is  valuable. 
>>> Maybe have the second sentence read like "When a dialog- establishing 
>>> INVITE causes multiple offer/answer exchanges due to  forking, these 
>>> offer/answer exchanges may use different patterns,  since they are 
>>> distinct."
>>
>> Covered earlier. I didn't follow your wording but I did borrow from  it.
>>
[TS]
As only intitial INVITE is dialog-establishing, we can use initial INVITE.
I think the logic here is;
 - multiple dialogs -> multiple/distinct offer/answers

How about

  When an initial INVITE causes multiple dialogs
  due to forking, an offer/answer exchange is
  occurred in each distinct dialog independently.

>> How about: "The 'Early' column indicates which patterns may be used  to 
>> modify the established session in an early dialog."
>>
>>> "...with an offer which it can not accept..."
>>> A tad awkward, and several occurances, suggest "...with an  unacceptable 
>>> offer..." as an alternative.
>>
>> Sounds good.
>>
>>> Section 3.1:
>>>  description if it has sent the offer which has not yet received the
>>> "To  avoid this glare condition, UA is recommended not to send an offer,
>>>  which currently must be in an UPDATE request, if it has generated the
>>>  reliable provisional response with the answer to the offer in the
>>>  INVITE request which is not acknowledged with a PRACK request."
>>> Awkward, I suggest
>>> "This glare condition can be avoided if the UA waits until the  receipt 
>>> of the PRACK to its answer-carrying 1xx-rel before sending  another 
>>> offer, which currently must be sent using an UPDATE request."
>>
>> I proposed something different above before I got to this. Does  that 
>> work for you?
>>
>
> Yeah, that looks good.
>
>>> Section 4.3:
>>> "However, its local
>>>  desired state will now be either "sendonly" or "inactive" according
> I'll probably give this a second pass in the near future, but I  imagine I 
> won't find much more than nits. All in all, this does an  excellent job of 
> motivating the material.
>
> Best regards,
> Byron Campen
>

Thanks,
Takuya

>>>> A New Internet-Draft is available from the on-line Internet- Drafts 
>>>> directories.
>>>> sessions. The descriptions on how to use offer/ answer in SIP are 
>>>> [email-masked] <mailto:i-d-announce- [email-masked]> 
>>>> with the word unsubscribe in the body of the  message. You can also 
>>>> visit https://www1.ietf.org/mailman/ listinfo/I-D-announce to change 
>>>> your subscription settings.
>>>>
>>>> logging in, type "cd internet-drafts" and then "get draft- 
>>>> Use [email-masked] <mailto:[email-masked]> for new developments of  core 
>>>> SIP
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2007 09:26:29 -0400

> Paul, do we need the reference to dialogue usage draft?

I think it would be good to include the reference.

	Paul