Subject: [Sip] New version (-04) of draft-ietf-sip-199

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 Jan 2009 09:48:56 +0100

Hi,

Based on comments and discussions, I've submitted a new version of the
199 draft.

The currently remaining to-do is to add text to the security chapter.

The draft can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt

Regards,

Christer
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 07 Jan 2009 11:10:32 +0000

Christer,

"If the received initial request contains an 199 option tag, the UAS
   SHOULD NOT send a 199 response for a dialog on which it intends to
   send a final response, unless it e.g. has been configured to do so
   due to lack of 199 support by forking proxies or other intermediate
   SIP entities."

I doubt that a UAS would implement a new configurable parameter just so
that it can reduce resource consumption at the UAC when the forking
proxy has not bothered to implement 199. It is far easier for the UAS
never to send 199. So is it really worth specifying this option?

"When a forking proxy receives a non-2xx final response which
   terminates one or more (if forking has occured downstream a final
   response received by the forking proxy MAY terminate multiple early
   dialogs), and the proxy does not intend to forward the final response
   immedialetly (due to the rules for a forking proxy), and the UAC has
   indicated support of the 199 response code, the proxy SHOULD generate
   and send a 199 response upstream for the early dialog on which the
   non-2xx final response was received, unless the proxy has previously
   recieved and forwarded a 199 response for the dialog."
Wow! We really must shorten this sentence. In particular I don't like
including a second normative sentence in parentheses within the main
sentence.

"If the forking proxy has stored the Contact and Record-Route headers
   for the early dialogs, it SHALL insert the headers in the 199
   responses."
Which Contact and Record-Route header fields? Presumably the ones
received from the UAS (as opposed to the UAC), but it doesn't make this
clear. Also, if there is no compulsion to store these header fields, why
make it mandatory to transmit them if they have been stored?

John 

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
	Sent: 07 January 2009 08:49
	To: [email-masked]
	Subject: [Sip] New version (-04) of draft-ietf-sip-199

	Hi, 

	Based on comments and discussions, I've submitted a new version
of the 199 draft. 

	The currently remaining to-do is to add text to the security
chapter. 

	http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt
<http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt>  

	Regards, 

	Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 Jan 2009 13:08:57 +0100

Hi John, 

>I doubt that a UAS would implement a new configurable 
>parameter just so that it can reduce resource consumption at 
>the UAC when the forking proxy has not bothered to implement 
>199. It is far easier for the UAS never to send 199. So is it 
>really worth specifying this option?

It is probably true that a SIP phone type of UAS would not implement a
new configurable parameter for this.

However, the UAS could be a "network entity", e.g. an application
server, or a B2BUA, and in such cases the operator may have a
configurable parameter. So, I think we should allow it.

>>dialogs), and the proxy does not intend to forward the 
>>final response immedialetly (due to the rules for a forking proxy),
and 
>>the UAC has indicated support of the 199 response code, the proxy 
>>SHOULD generate and send a 199 response upstream for the early dialog
on which the
>>non-2xx final response was received, unless the proxy has 
>>previously recieved and forwarded a 199 response for the dialog."
>
>Wow! We really must shorten this sentence. In particular I 
>don't like including a second normative sentence in 
>parentheses within the main sentence.

I can try to think of more simple wording. 

And, text suggestions are of course always welcome :)

>Which Contact and Record-Route header fields? Presumably the 
>ones received from the UAS (as opposed to the UAC), but it 
>doesn't make this clear.

Yes, that should be clarified.

>Also, if there is no compulsion to store these header fields, why make
it mandatory to transmit 
>them if they have been stored?

I was requested to add text about the possibility to store the header
fields and included them in the response. I see no harm in doing so,
since storing the parameters is optional anyway.

Regards,

Christer

> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> 	Based on comments and discussions, I've submitted a new 
> version of the 199 draft. 
>

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 7 Jan 2009 09:11:11 -0500

> > "If the forking proxy has stored the Contact 
> > and Record-Route headers for the early dialogs, 
> > it SHALL insert the headers in the 199 responses."

<snip>

> > Also, if there is no compulsion to store these 
> > header fields, why make it mandatory to transmit 
> I was requested to add text about the possibility 
> to store the header fields and included them in 
> the response. I see no harm in doing so, since 
> storing the parameters is optional anyway.

For clarity, the following is a snippet from my 11/17/2008
draft-ietf-sip-199-02 comments and questions posting to the sip list.  I
don't have strong preference concerning the normative strength to
include (or not include) the headers.

http://www.ietf.org/mail-archive/web/sip/current/msg25605.html

"Section 6 paragraph 2 last sentence: Since using another's To tag when
sending the 199, the draft should mention something concerning headers
Contact and Record-Route.  If proxy chooses not to add them, a missing
Contact and Record-Route will not be an issue for UAC; however another
proxy (not supporting this draft) may be surprised to see their
Record-Route entry missing.  Additionally since this draft defines a 1xx
with To tag which does not create a dialog (unless section 4 paragraph 4
modified), does this draft update RFC 3261?"

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 7 Jan 2009 12:20:27 -0500

>>>immedialetly (due to the rules for a forking proxy),
>and 

Along the same lines, I found text about support for 100rel also
confusing. I think the preference is that this response be not sent
reliably, though the normative strength is slightly week for UAS as
compared to a forking proxy. I think it should be simplified and just
say that 100rel option does not have significance for this. As an
addition, it will also simplify it's association with offer-answer
exchange (fact that 199 should have offer sdp for delayed media Invite)

Sanjay

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 07 Jan 2009 17:22:12 +0000

Christer,

> And, text suggestions are of course always welcome :)
How about:
"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a forking
proxy) and the UAC has indicated support for the 199 response code, the
proxy SHOULD generate and send a 199 response upstream for each early
dialog terminated on the downstream side by the non-2xx final response,
except for any early dialog for which the proxy has previously received
and forwarded a 199 response. Note that if forking has also occurred
downstream of the forking proxy, a final response received by the
forking proxy can terminate multiple early dialogs."

I have removed the normative statement that was in parentheses and
created a separate sentence at the end. However, I believe it does not
need to be normative - it is just a statement of something that arises
because of the normative provisions of RFC 3261.

I believe the proxy should send a 199 response on EACH affected early
dialog (unless 199 already sent). This too is reflected in my proposed
rewording.

I hope this helps.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 Jan 2009 20:36:39 +0100

Hi John, 

>>>>dialogs), and the proxy does not intend to forward the final 
>>>>response immedialetly (due to the rules for a forking proxy),
>>>>and the UAC has indicated support of the 199 response code, the
proxy 
>>>>on which the non-2xx final response was received, unless the proxy
has previously 

one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a 
>forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated on the downstream side by the 
>non-2xx final response, except for any early dialog for which the proxy
has previously received and forwarded a 199 response. Note that if
forking has also occurred downstream of the forking proxy, a 
>final response received by the forking proxy can terminate multiple
early dialogs."
created a separate sentence at the end. However, I believe it does not
need to be normative - it is just a statement of something that 
>arises because of the normative provisions of RFC 3261.
>

That is covered in the existing text:

"If the forking proxy generates a 199 response, and if the forking proxy
is able to
identify additional early dialogs which are terminated by the same
non-2xx final response, it MUST also generate and send a 199 response
upstream for each of those early dialogs, except for any dialog on
which the proxy has previously received and forwarded a 199 response."

I don't mind working with your proposal, but I think it important to
keep the "IF the forking proxy is able to identify additional early
dialogs" part, because the forking proxy may not be able to associate
other early dialogs with the non-2xx response.

One proposal would be the following:

"When a forking proxy receives a non-2xx final response that terminates
one or more early dialogs, if the proxy does not intend to forward the
final response immediately (in accordance with rules for a 
forking proxy) and the UAC has indicated support for the 199 response
code, the proxy SHOULD generate and send a 199 response upstream for
each early dialog terminated (if the forking proxy is able to identify
additional early dialogs that are terminated by the non-2xx final
response) on the downstream side by the non-2xx final response, except
for any early dialog for which the proxy has previously received and
forwarded a 199 response. Note that if forking has also occurred
downstream of the forking proxy, a final response received by the
forking proxy can terminate multiple early dialogs. Based on
implementation policy, the proxy MAY wait before sending the 199
response, e.g. if the proxy expects to receive a 2xx final response on
another dialog shortly after it received the non-2xx final response
which triggered the 199 response."

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 Jan 2009 20:42:01 +0100

Hi, 

proxy 
has previously 

>exchange (fact that 199 should have offer sdp for delayed media Invite)

Well, one of the previous open issues were whether it should be allowed
to send 199 reliably, and the proposed way forward was to allow the UAS
to send it reliably.

Regards,

Christer

---

From: "Doken, Serhad" <[email-masked]>
Date: Wed, 7 Jan 2009 13:55:36 -0800

Last sentence in 3rd paragraph in Sec 1:

"When SIP entities upstream receive the first 2xx final response, and they do not to intend to accept

subsequent 2xx final responses, they will automatically terminate other associated outstanding early

dialogs. If additional 2xx final responses are received, for INVITE initiated dialogs those SIP

entities will normally send a BYE request using the dialog identifier retrieved from the subsequent

2xx final response."

since the context is 199 and early dialogs, do we need the reference to INV or can we simplify say  :

"If additional 2xx final responses are received, they will send a BYE request using the dialog identifier retrieved from the subsequent

2xx final response"

Sec 4.1, last sentence, readability is better if modified as :

"...if a 199 response is received for that early dialog, client terminates it. Afterwards, client SHOULD act as before the first early dialog as established

Other nits:
Sec 1 and 4, decissions -> decisions
Sec4, dialogusage -> dialog usage
          desribed -> described
Sec 4.1example 6, diaogs ->dialogs
Sec 4.2, announcement -> announcement
Sec 6, immedialetly > immediately
           occurred -> occurred
           received -> received
           reliably  -> reliably
           prxy -> proxy
Sec 7, compability -> compatibility

Thanks,
Serhad

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, January 07, 2009 12:49 AM
To: [email-masked]
Subject: [Sip] New version (-04) of draft-ietf-sip-199

Hi,

Based on comments and discussions, I've submitted a new version of the 199 draft.

Regards,

Christer

---

From: "Kanumuri, Sreeram" <[email-masked]>
Date: Wed, 7 Jan 2009 18:06:11 -0800

Hi,

Here are my comments on the draft:

>From section 9
>NOTE: If the INVITE request did not contain an SDP offer, and the 199
>response is the first reliably sent response, the 199 response is
>required to contain an SDP offer.

Can you make clear about the SDP-offer more clearly..

>From sec 10 it looks like 199 is not send reliably
but from sec 9 ,"the 199 response is the first reliably sent response is required to contain an SDP offer".

I would say, we may not get a case where we will be ending up sending SDP-offer in 199.

Thanking you,

Regards,
Sreeram

Hi,

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 Jan 2009 07:20:34 +0100

Hi Sreeram,
 
An UAS is currently allowed to send 199 reliably (a forking proxy is not
allowed to do it).
 
Regards,
 
Christer

	From: Kanumuri, Sreeram [mailto:[email-masked]] 
	Sent: 8. tammikuuta 2009 4:06
	To: Christer Holmberg; [email-masked]
	Subject: RE: New version (-04) of draft-ietf-sip-199

	Hi,

	From section 9

	but from sec 9 ,"the 199 response is the first reliably sent
response is required to contain an SDP offer".

	I would say, we may not get a case where we will be ending up
sending SDP-offer in 199.

	Thanking you,

	Regards,

	Sreeram

	 

	Hi, 

	Regards, 

	Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 Jan 2009 07:58:16 +0100

Hi Serhad,

>"If additional 2xx final responses are received, they will send a BYE
request using the dialog identifier retrieved from the subsequent
>2xx final response"

Looks ok.

>"...if a 199 response is received for that early dialog, client
terminates it. Afterwards, client SHOULD act as before the first early
dialog as established

Ok. So, the new text would be something like (with some minor additional
editorials):	 

"If the client only has a single early dialog (other early dialogs MAY
not have been established, or they MAY have been established and
later terminated) and a 199 response is received for that early
dialog, the client terminates it. Afterwards, the client after 
the client SHOULD act as before the first early dialog
was established."

>Sec 7, compability -> compatibility

I'll fix those.

Thank You for the comments! :)

Regards,

Christer

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christer Holmberg
	Sent: Wednesday, January 07, 2009 12:49 AM
	To: [email-masked]
	Subject: [Sip] New version (-04) of draft-ietf-sip-199

	Hi, 

	Regards, 

	Christer