Subject: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11

From: "Siddhartha Bhakta" <[email-masked]>
Date: Fri, 10 Nov 2006 15:54:55 -0000

Thomas's suggestion sounds good. If forking proxy needs to pass 18x
downstream, it should NOT put to-tag.

However, that shall put the restriction that PRACK can not be sent for that
18x messages since PRACK can only be sent over established dialog. If 18x
response does not contain to-tag, it can not create dialog.

That may be worth bet compared to all dialog related mess up in this case.

Best regards,

Siddhartha

Date: Fri, 10 Nov 2006 16:30:55 +0100

From: [email-masked]

Subject: Re: [Sipping] Query related to

      draft-ietf-sipping-service-examples-11

To: [email-masked]

Cc: [email-masked]

Message-ID: <[email-masked]>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

[email-masked] wrote:

>    From: [email-masked]

>    I agree with that point, it is particularly tricky for UAs

>    implementations to receive a first 1xx with a toTag, and then, and

>    200 OK with another one...

> How could a UA support forking generally and not handle this case 

> smoothly?

Theoritically, you are right :-), in practice, after 5 SIPIT, forking is not
always so well supported by UAs (and proxies, by the way), probably because
this is complex to implement... I still think that a proxy "muted
temporarily" to a UAS is something unecesssary complex, it could be possible
to say that a proxy sending 1xx reponses should NOT put any totag, (as for
100 trying)... So easy to say, so easy to implement...

Best regards,

Thomas

---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Nov 2006 14:04:52 -0500

The kind of change you describe is in fact a normative change. To get 
such a change made, you will have to explain why there is currently a 
problem that needs fixing. I don't think you have a case for that.

The bookkeeping to manage the multiple dialogs is currently already 
required for forking, so no added implementation is required. At worst 
it requires a little extra storage for state retention in some cases 
where the proposed change might avoid that.

Note that in case of forking it is necessary to retain early dialogs 
until a final response is received. If the final result is failure then 
the UA can immediately drop all the dialogs. If the result is success, 
then the other dialogs need to be retained long enough for any other 2xx 
responses in transit to arrive.

	Paul

Siddhartha Bhakta wrote:
> Thomas’s suggestion sounds good. If forking proxy needs to pass 18x 
> However, that shall put the restriction that PRACK can not be sent for 
> that 18x messages since PRACK can only be sent over established dialog. 
> If 18x response does not contain to-tag, it can not create dialog.
> 
>  
> 
> Theoritically, you are right :-), in practice, after 5 SIPIT, forking is 
> not always so well supported by UAs (and proxies, by the way), probably 
> because this is complex to implement... I still think that a proxy 
> "muted temporarily" to a UAS is something unecesssary complex, it could 
> be possible to say that a proxy sending 1xx reponses should NOT put any 
> totag, (as for 100 trying)... So easy to say, so easy to implement...
> 
>  
> 
> Best regards,
> 
> Thomas
> 
>  
> 
> 
> 
> ------------------------------------------------------------------------
> ---------------
> This e-mail may contain confidential and/or privileged information. If 
> you are not the intended recipient (or have received this e-mail in 
> error) please notify the sender immediately and delete this e-mail. Any 
> unauthorized copying, disclosure or distribution of the contents in this 
> e-mail is strictly forbidden.
> ---------------
> 
> 
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Fri, 10 Nov 2006 20:13:13 +0100

Paul Kyzivat wrote:
> required for forking, so no added implementation is required. 
In that case, why not completely deprecate forking itself?
.. just kidding ^_^...

---

From: [email-masked]
Date: Fri, 10 Nov 2006 23:30:10 -0500

Heh -- you know that has been seriously proposed.  But like jumping a
chasm, it's not something to be done by halves.  Until you actually
eliminate forking, you can't twiddle the parts of the protocol that
are needed to cope with forking.

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Nov 2006 13:00:07 -0600

> In that case, why not completely deprecate forking itself?

Pure genius! Best idea I've heard all week. Hey, I may not be allowed  
to suggest it myself, but I can applaud when someone else does. At  
least until the WG takes a hum on that one too . . .

--
dean