Subject: [Sip] Questions about "draft-ietf-sip-199-05"

From: Eric wang <[email-masked]>
Date: Mon, 23 Feb 2009 23:16:46 +0800

Hi Christer,
    Glad to see that the draft starts its WGLC process.It's really useful.

    I still have some difficult in using IETF and cannot find the whole
sorted comments about this draft, so i have some doubt about this draft.

   1.   "If a forking proxy receives a reliably sent 199 response for a

   dialog, for which the proxy has previously generated and sent a 199

   response, the proxy MUST forward the 199 response."
     Does it describe the case below? Although P1 have sent a 199 response,
P1 havs to  forword the send reliably 199 too.Or  is the  first 199 mistaked
for 18x?

          UAC               P1                  UAS_2
       --- INVITE ------>
                         --- INVITE (leg 2) ->
       <-- 199(leg 2) --
                         <-- 199 (leg 2) -----
       <-- 199(leg 2) --

     2.  "10.  Usage with 100rel

   When a 199 Early Dialog Terminated provisional response is sent by a

   UAS, since the provisional response is only used for information

   purpose, the UAS SHOULD send it unreliably even if the 100rel option

   tag [RFC3262] is present in the Require header of the associated

   request."

   I have seen a comment on this question,but still not understood about it
.

   If the INVITE has a Require tag "Require: 100rel",does the UAS still use

   unreliable 199 response?

   If 199 is reliable, there is one more advantage. If the 199 arrives
before

   the first 18x response, UAC can discard the first 199 and process it
until

   UAC receives the first 18x response that has the same to-tag as 199, as

   the reliable 199 should be re-transmited until  received PRACK.

   ps:

   Can anyone show me how to sort all comments of a topic by time?

   Regards,

   Eric.wang

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 13:24:20 +0100

Hi, 

>Glad to see that the draft starts its WGLC process.

Well, that is what I requested at least :)

>
>     Does it describe the case below? Although P1 have sent a 199
response, P1 havs to  forword the send reliably 199 too.Or  is the
first 199 mistaked for 18x?
>            <-- 199(leg 2) --
 
I think it shall be 199, as currently written.

UAS, since the provisional response is only used for information
purpose, the UAS SHOULD send it unreliably even if the 100rel 
>   option tag [RFC3262] is present in the Require header of the
associated request."
>
>   
>I have seen a comment on this question,but still not understood about
it. If the INVITE has a Require tag "Require: 100rel",does the UAS still
use unreliable 199 response?

That is the recommendation, yes. The reasons is that we want to keep 199
as "lightweight" as possible, without requireing re-transmissions and
PRACKs.

>If 199 is reliable, there is one more advantage. If the 199 arrives
before the first 18x response, UAC can discard the first 199 and process
it until UAC receives the first 18x response that has the same 
>to-tag as 199, as the reliable 199 should be re-transmited until
received PRACK.

If the INVITE contains "Require: 100rel", the first 18x must also be
sent reliably. And, I don't think the UAS is allowed to send another
reliable response until the first one is acknowledged, so I don't think
a reliable 199 would reach the UAC before the first reliable 18x.

>Can anyone show me how to sort all comments of a topic by time?

Unless it can be done by sorting the e-mails by subject it is kinda
difficult.

Regards,

Christer

---

From: Eric wang <[email-masked]>
Date: Thu, 26 Feb 2009 22:37:30 +0800

Hi Christer,
   Thanks for replying.
   Comments are maked with [Eric] below. 3ks.

[Eric]: If  this is 199, then Is there a special purpose to send two 199 in
the same dialog?
I think that one 199 is enough.
And  the first 199 may be reliable too, that will make it a little difficult
to send the second 199.

associated request."

[Eric]: But reliable 199 have more advantage, and It is worth to use the
reliable 199,I think.

received PRACK.

[Eric]: Surely the UAS is allowed to send another reliable response until
the first one is acknowledged, but reliable 199 will be useful if the first
18x is unreliable, or
the first 18x has been acknwledged.
It's another case different from the above one  whose INVITE contains
"require: 100rel".

Regards,

Christer

Regards,

Eric.wang

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 20:04:03 +0100

Hi,

>[Eric]: If  this is 199, then Is there a special purpose to send two
199 in the same dialog?
>And  the first 199 may be reliable too, that will make it a little
difficult to send the second 199.
 
The second 199 could include information which is to be forwarded to the
UAC.

associated request."
>[Eric]: But reliable 199 have more advantage, and It is worth to use
the reliable 199,I think.

I don't know what that advantage would be, compared to having to send
PRACKs etc. This has been discussed quite much, so I would really need
some good justification to change it now.

Also, the draft doesn't forbid you to send the 199 reliably. It's only a
SHOULD.

>[Eric]: Surely the UAS is allowed to send another reliable response
until the first one is acknowledged,

If I remember correctly, the FIRST reliable response must be acknowleded
before the next reliable response is sent. But, we can double check in
the PRACK spec.

>but reliable 199 will be useful if the first 18x is unreliable, or the
first 18x has been acknwledged. It's another case different from the
above one  whose INVITE contains "require: 100rel".

If 100rel is required the 18x cannot be unreliable.

Regards,

Christer

---

From: [email-masked]
Date: Fri, 27 Feb 2009 09:06:23 +0800

Hi,

And there still two questions left.

1.  Is the 199 should be reliable or unreliable?
    I think that 199 should be reliable if possible.

   First, If a client receives an unreliable 199 response on a dialog 
which has
   not previously been created (this can happen if a 199 response
   reaches the client before a 18x response) the client SHALL discard
   the 199 responses.

   The figure below shows an example.The 180 is sent first but arrives 
later than 199.
If the 199 is reliable, the proxy should retransmit 199 (step 4),and then 
the retransmitted
199 will be accepted by UAC,and the early dialog will be teminated.

UAC             P
   1. INVITE
--------------->
          2. 180
<----- \/-------
       /\ 3. 199
<-----/  \------
          4. 199(retransmitted)
<---------------

   second, According to practical use, 199 can be intended to teminate one 
early dialog and release 
resources associated with the specific early dialog, so the cost spent on 
reliable 199 is worthy.
If the 199 cannot be sent reliable,then we should send it unreliable.
 
2. In your last letter, you said "the second 199 could include information 
which is to be forwarded to the
UAC", then do you mean, the early dialog is still alive after the first 
199 is accepted?

Also, In my last letter, I miss a "NOT" by mistake. 
It should be 
[Eric]: Surely the UAS is NOT allowed to send another reliable response
until the first one is acknowledged...

Regards,
Eric wang

"Christer Holmberg" <[email-masked]> 
2009-02-27 03:04

收件人
"Eric wang" <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: Questions about "draft-ietf-sip-199-05"

Hi,

199 in the same dialog?

associated request."

Regards,

Christer

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Feb 2009 20:56:27 -0500

*allowing* (much less *requiring*) the 199 to be reliable introduces
nasty problems. The 199 is only an optimization, so having it be
unreliable is ok IMO.

The problem is that if a proxy sends the 199, then the recipient of the
PRACK should be the proxy. But the PRACK is an in-dialog message, so it
must be addressed to the Contact of the UAS.

If the proxy sends a reliable 199, and the PRACK is addressed to the
UAS, the UAS will be very surprised, since it has not send a reliable
provisional, and is so not expecting a PRACK. In fact, it has sent a
final response, has presumably already received the ACK, and so is
expecting nothing.

Very ugly.

	Paul

[email-masked] wrote:
> If the 199 is reliable, the proxy should retransmit 199 (step 4),and 
> then the retransmitted
>    second, According to practical use, 199 can be intended to teminate 
> one early dialog and release
> resources associated with the specific early dialog, so the cost spent 
> on reliable 199 is worthy.
> 2. In your last letter, you said "the second 199 could include 
> information which is to be forwarded to the
> *"Christer Holmberg" <[email-masked]>*
> 
> 2009-02-27 03:04
> 
> 	
> 收件人
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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: [email-masked]
Date: Fri, 27 Feb 2009 12:38:21 +0800

Hi,
 
   Practically, when Call forward and fork are used in the same system, 
there are 
lots of early dialogs that should be eliminated by 199 existed.
So I think that it's useful to let 199 reliable. 
   And we just added fork-service to our system ,and find 199 is really 
useful, and
if the 199 is missing, problems will happen.

   It sounds good that there is a way to prevent PRACK addressed to 
UAS,but i don't know
how to do now.
 
ps:
   RFC3261 16.7 Response Processing 
        Since a proxy may not insert a tag into the To header field of
         a 1xx response to a request that did not contain one, it cannot
         issue non-100 provisional responses on its own.

Eric

Paul Kyzivat <[email-masked]> 
2009-02-27 09:56

收件人
[email-masked]
抄送
Christer Holmberg <[email-masked]>, [email-masked]
主题
Re: [Sip] 答复: RE: Questions about "draft-ietf-sip-199-05"

Very ugly.

                 Paul

[email-masked] wrote:
> ZTE Information Security Notice: The information contained in this mail 
is solely property of the sender's organization. This mail communication 
is confidential. Recipients named above are obligated to maintain secrecy 
and are not permitted to disclose the contents of this communication to 
others.
> This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
originator of the message. Any views expressed in this message are those 
of the individual sender.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 07:01:26 +0100

Hi Paul, 

>*allowing* (much less *requiring*) the 199 to be reliable introduces nasty problems. The 199 is only an optimization, so having it be unreliable is ok IMO.
>
>The problem is that if a proxy sends the 199, then the recipient of the PRACK should be the proxy. But the PRACK is an in-dialog message, so it must be addressed to the Contact of the UAS.
>
>If the proxy sends a reliable 199, and the PRACK is addressed to the UAS, the UAS will be very surprised, since it has not send a reliable provisional, and is so not expecting a PRACK. In fact, it has 
>sent a final response, has presumably already received the ACK, and so is expecting nothing.
>
>Very ugly.

Just to clarify, a proxy MUST NOT send it reliably. The text in chapter 10 says:

"When a forking proxy generates a 199 response, the response MUST NOT be sent reliably."

The reason is, as Paul indicated, that the proxy would need to terminate the PRACK.

A UAS is allowed to send 199 reliably, but the tex says that it SHOULD be sent unreliably.

Regards,

Christer

[email-masked] wrote:
> one early dialog and release resources associated with the specific 
> early dialog, so the cost spent on reliable 199 is worthy.
> information which is to be forwarded to the UAC", then do you mean, 
> the early dialog is still alive after the first
> 199 is accepted?
> 
> 
> [Eric]: Surely the UAS is NOT allowed to send another reliable 
> response until the first one is acknowledged...
> 
> Regards,
> Eric wang
> 
> 
> 
> 
> The second 199 could include information which is to be forwarded to 
> the UAC.
> 
> 
>  >I have seen a comment on this question,but still not understood 
> about  >it. If the INVITE has a Require tag "Require: 100rel",does the 
> UAS still  >use unreliable 199 response?
>  >
>  >as "lightweight" as possible, without requireing re-transmissions 
> and  >PRACKs.
>  >
> Also, the draft doesn't forbid you to send the 199 reliably. It's only 
> a SHOULD.
> 
> 
> >before the first 18x response, UAC can discard the first 199 and 
> process  >it until UAC receives the first 18x response that has the 
> same  >to-tag as 199, as the reliable 199 should be re-transmited 
> until  >received PRACK.
>  >
> >reliable response until the first one is acknowledged, so I don't 
> think  >a reliable 199 would reach the UAC before the first reliable 18x.
>  >
> If I remember correctly, the FIRST reliable response must be 
> acknowleded before the next reliable response is sent. But, we can 
> double check in the PRACK spec.
> 
>  >but reliable 199 will be useful if the first 18x is unreliable, or 
> the first 18x has been acknwledged. It's another case different from 
> the above one  whose INVITE contains "require: 100rel".
> 
> 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: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 07:13:20 +0100

Hi,

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 27, 2009 3:06 AM
To: Christer Holmberg
Cc: [email-masked]
Subject: [Sip] 答复: RE: Questions about "draft-ietf-sip-199-05"

Hi, 

> 1.  Is the 199 should be reliable or unreliable?  
 
SHOULD be unreliable (if sent from a UAS).
 
>First, If a client receives an unreliable 199 response on a dialog which has 
>The figure below shows an example.The 180 is sent first but arrives later than 199. 
>If the 199 is reliable, the proxy should retransmit 199 (step 4),and then the retransmitted 
 
In my opinion it would be much wiser to send the 180 relaibly in this case, and then send 199 once the 180 has been acknowledged.

>second, According to practical use, 199 can be intended to teminate one early dialog and release 
>resources associated with the specific early dialog, so the cost spent on reliable 199 is worthy. 
>2. In your last letter, you said "the second 199 could include information which is to be forwarded to the UAC", then do you mean, the early dialog is still alive after the first 199 is accepted?  
 
No. But there has been discussions to e.g. include the error response which triggered the 199, so that the UAC gets more information on WHY the early dialog was terminated.
 
Regards,
 
Christer

2009-02-27 03:04 

收件人

Hi,

199 in the same dialog?

associated request."

>before the first 18x response, UAC can discard the first 199 and
process

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 07:23:02 +0100

Hi,
  
>Practically, when Call forward and fork are used in the same system, there are 
>And we just added fork-service to our system ,and find 199 is really useful, and 
 
I'm glad you think 199 is useful :)
 
But, if a proxy would have to terminate PRACKs etc it would not be a proxy anymore - it would be a B2BUA.
 
So, if you really want your network to send 199 reliably, I guess you could use a B2BUA instead of a proxy.

>It sounds good that there is a way to prevent PRACK addressed to UAS,but i don't know  how to do now. 
 
The only way to prevent it is by the proxy not sending the 199 relaible.  
    
>issue non-100 provisional responses on its own.  
 
Yes, but I we have agreed that a proxy is allowed to send 199.
 
But, the proxy is not going to generate new To header tag values for the 199. It will use whatever tags that have already been created for the early dialogs. 
 
Regards,
 
Christer

 

Very ugly.

                Paul

---

From: Eric wang <[email-masked]>
Date: Fri, 27 Feb 2009 18:49:16 +0800

hi,

   If the UAC requires 100rel ,then what should the proxy do if it receives
a no-2xx
final response after forking?

Regards,
Eric

2009/2/27, Christer Holmberg <[email-masked]>:
> >RFC3261 *16.7 Response Processing*
> But, the proxy is not going to generate new To header tag values for the
> 199. It will use whatever tags that have already been created for the early
> dialogs.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
> is solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to others.
> originator of the message. Any views expressed in this message are those of
> the individual sender.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 12:00:36 +0100

Hi,
 
>If the UAC requires 100rel ,then what should the proxy do if it receives a no-2xx   final response after forking? 
 
The proxy should send 199 unreliably.
 
Regards,
 
Christer 

	Hi,

	 

	 

	 
	 
	Regards,

	Christer

	 

	

	Very ugly.
	
	                Paul

---

From: Eric wang <[email-masked]>
Date: Fri, 27 Feb 2009 19:10:29 +0800

hi,

 I don't think the 199 can be sent unreliably if UAC require 100rel.
As in RFC3262, It says.

 The UAS MUST send any non-100 provisional response reliably if the
   initial request contained a Require header field with the option tag
   100rel.  If the UAS is unwilling to do so, it MUST reject the initial
   request with a 420 (Bad Extension) and include an Unsupported header
   field containing the option tag 100rel.

Regards,
Eric

2009/2/27, Christer Holmberg <[email-masked]>:
> a no-2xx   final response after forking?
>
>> think

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 12:21:39 +0100

Hi,
>    field containing the option tag 100rel. 
 
This has been discussed, and the proposed outcome was to allow 199 to be sent unreliably even if 100rel is required.
 
Regards,
 
Christer

	Hi,

	 
	Regards,

	Christer 

		Hi,

		 

		 

		 
		 
		Regards,

		Christer

		 

		

		Very ugly.
		
		                Paul

---

From: "Eric.wang" <[email-masked]>
Date: Fri, 27 Feb 2009 19:35:35 +0800

Dear Christer,

   It seems I’d better review all your comments firstJ.

   Thank you for answering my question.

Best regards,

Eric

发件人: Christer Holmberg [mailto:[email-masked]] 
发送时间: 2009年2月27日 19:22
收件人: Eric wang
抄送: [email-masked]; Paul Kyzivat; [email-masked]
主题: RE: [Sip] 答复: RE: Questions about "draft-ietf-sip-199-05"

Hi,

Regards,

Christer

 

Hi,

Regards,

Christer 

Hi,

    

Regards,

Christer

 

 

Very ugly.

                Paul

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 27 Feb 2009 14:39:29 +0100

Christer,

The B2BUA should only send the 199 reliably if the Contact header has been mapped in the B2BUA.

If the B2BUA has not mapped the Contact then you have a similar problem to that of the proxy. 

The B2BUA could of course intercept the PRACK and send the 200 OK even though the PRACK was addressed to the Contact provided in the initial response to the INVITE.

To use Paul’s words – “ugly”.

Ian Elz

From: Christer Holmberg 
Sent: 27 February 2009 06:23
To: [email-masked]; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Sip]??: RE: Questions about "draft-ietf-sip-199-05"

Hi,

    

Regards,

Christer

 

 

Very ugly.

                Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 20:51:07 +0100

Hi,

>If the B2BUA has not mapped the Contact then you have a similar problem to that of the proxy.  

Yes, I guess I could have clarified that. My point was that if you do want a network entity to send the 199 reliably it has to be a B2BUA. 

>The B2BUA could of course intercept the PRACK and send the 200 OK even though the PRACK was addressed to the Contact provided in the initial response to the INVITE. 

Sure, but I think the outcome of the discussons has been that we don't want to do that.

And, at the end of the day people can implement whatever they want :)

Regards,

Christer

From: Christer Holmberg 

Hi,

    

Regards,

Christer

 

 

Very ugly.

                Paul