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

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

Dear Brett,

For forking, SIP entity shall send multiple INVITE with different branch
parameter. As s result, it shall receive response corresponding to different
INVITEs. Those shall create multiple dilaogs. Here each of the dialogs are
having separate INVITE messages.

I am discussing sec 2.9, where Alice is sending single INVITE(F1) but it is
receiving 1xx with different to-tags. Now the question is that, whether
single INVITE can result into multiple dialogs? I thought that forking proxy
shall manage all the forked dialogs and select one dialog as the best dialog
and pass response downstream for that dialog only. That way Alice shall only
see single dialog where proxy shall manage two forked dialog in this
example.

Please clarify.

Message: 5

Date: Fri, 10 Nov 2006 09:28:13 -0500

From: "Brett Tate" <[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="us-ascii"

> > 181 is one of those types of responses for which I tend to think: 

> > wouldn't that work better without a to-tag?

> 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...

> I general, they report a bug to proxy implementor ;-) and after 

> realizing it is the "virtual UAS" case in RFC, they start to classify 

> this as "evil" feature...

> That's true that UAs should support forking, and thus, be capable of 

> receiving multiple toTag, but is just not very often supported from my 

> experience...

User Agents expecting offer/answer compliance must support forking proxies
and thus 18x's and 2xx's with different To tags.

I discuss some of the reasons within the following link.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-November/0

14620.html

---------------
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: "Brett Tate" <[email-masked]>
Date: Fri, 10 Nov 2006 13:22:10 -0500

> I am discussing sec 2.9, where Alice is sending 
> single INVITE(F1) but it is receiving 1xx with 
> different to-tags. Now the question is that, 
> whether single INVITE can result into multiple 
> dialogs? 

I'm not positive what you mean by "single INVITE".  However the answer
is yes for both forking and "virtual" forking situations.

> I thought that forking proxy shall manage all 
> the forked dialogs and select one dialog as 
> the best dialog and pass response downstream 
> for that dialog only. That way Alice shall 
> only see single dialog where proxy shall manage 
> two forked dialog in this example.

The example results in 3 early dialogs.  Prior to the RFCs which imposed
various offer/answer restrictions, a B2BUA could do something similar to
what you are suggesting (with some limitations).

RFC 3261 section 16.7 discusses what a proxy should do if it wants to
generate a non-100 provisional response.

"1xx and 2xx responses may be involved in the establishment of
dialogs.  When a request does not contain a To tag, the To tag
in the response is used by the UAC to distinguish multiple
responses to a dialog creating request.  A proxy MUST NOT
insert a tag into the To header field of a 1xx or 2xx response
if the request did not contain one.  A proxy MUST NOT modify
the tag in the To header field of a 1xx or 2xx response.

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.  However, it
can branch the request to a UAS sharing the same element as the
proxy.  This UAS can return its own provisional responses,
entering into an early dialog with the initiator of the
request.  The UAS does not have to be a discreet process from
the proxy.  It could be a virtual UAS implemented in the same
code space as the proxy."

I do not have a strong opinion concerning the sending of 181 (without
SDP) when the proxy has received the 487 response.  There are 3 options;
however only option 1 is compliant with rfc3261.

1) Follow service example and add new To tag.  This is the only rfc3261
compliant solution.

2) Use the To tag of the received failure response.  This is non
complaint to rfc3261 and requires waiting for the 487.  The reason that
it might be nice is because allowing this to be valid would easily allow
a new 1xx response code to be sent by a forking proxy to indicate when a
particular early dialog no longer exists.  However there are definitely
other ways to solve that problem.

3) Send non-100 1xx responses without To tag.  This provides extra
ambiguity; and this is especially true when multiple forking proxies are
involved.  And it is non compliant to rfc3261.

---

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

Well, I think that there is no way for the UAC to discover that the
proxy is faking it, as the UAS could have sent a 1xx followed by the
487, but the network reordered the responses.  So this scenario is not
visibly different from RFC 3261 compliance.

But there are still problems:  One you mention is that the 1xx can't
be sent until the 487 is received by the proxy, so no time is gained
-- the proxy might as well send the 487 on to indicate that the early
dialog is ended.  The other is that the 1xx isn't reliably delivered,
and so it can only be used for advisory information, limiting the
value of such a device.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 12 Nov 2006 17:50:56 +0100

> SDP) when the proxy has received the 487 response.  There are 3
> options; however only option 1 is compliant with rfc3261.
>
> 1) Follow service example and add new To tag.  This is the only
> rfc3261 compliant solution.
>

As I wrote in a separate response, if we were to combine this with the proxy 
not inserting a Contact, and have the UAC interpret that as "does not want 
to continue with this dialog" (or at least "can safely postpone creating an 
early dialog until a next response with a valid Contact arrives"), we could 
have ourselves a workable solution.

Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 12:33:08 -0500

I think solutions like this might have been good if they had been 
incorporated originally. But adding such behavior now is of dubious 
value. It doesn't save any work because of the need to be backwards 
compatible.

	Paul

Jeroen van Bemmel wrote:
> As I wrote in a separate response, if we were to combine this with the 
> proxy not inserting a Contact, and have the UAC interpret that as "does 
> not want to continue with this dialog" (or at least "can safely postpone 
> creating an early dialog until a next response with a valid Contact 
> arrives"), we could have ourselves a workable solution.
> 
> Jeroen
> 
>