Subject: [Sip] Outbound and mid-dialog requests with GRUU

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 11:46:52 -0500

Here's a question:

A UA has registered two flows to one instance. It has one gruu. The UA  
uses the gruu as the contact in a dialog-forming request.

An in-dialog request (for example, BYE) is sent back  to the UA. On  
which flow does it get routed?

I believe: It gets routed on the flow that formed the dialog, as long  
as that flow exists. The proxy has stored dialog state and knows which  
flow the dialog-forming request used.

The GRUU spec assumes one contact per gruu. Outbound transforms this  
to multiple contacts and multiple flows per gruu. I think this  
requires further specification as to flow selection, possibly for out- 
of-dialog messages and almost definitely for in-dialog messages.  
Perhaps this is documented somewhere and I've just missed it.

Any clues?

--
Dean
_______________________________________________
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] (Juha Heinanen)
Date: Fri, 17 Oct 2008 20:00:03 +0300

> Any clues?

it is very revealing that at the stage when these i-d are about to go to
rfc editors for publishing, there is lots of all kind of issues that
even the experts are not sure about.

even if these issues finally get sorted out on the list, there is
absolutely no chance whatsoever that an average implementer who has not
participated in these discussions could even get his/her implementation
correct.  these specifications are far too complicated for that.

it should be a high time to take a timeout and go back to the basics.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2008 13:21:00 -0400

> which flow does it get routed?

 From gruu-15:

    If there are no registered contacts bound to the GRUU, the server
    MUST return a 480 (Temporarily Unavailable) response.  If there are
    more than one, there are two cases:

    1.  The client is using draft-ietf-sip-outbound [13] and registering
        multiple contacts for redundancy.  In that case, these contacts
        contain reg-id Contact header field parameters, and the rules
        described in Section 7 of draft-ietf-sip-outbound [13] for
        selecting a single registered contact apply.

    2.  The client was not using SIP outbound, in which case there would
        only be multiple contacts with the same instance ID if the client
        had rebooted, restarted and re-registered.  In this case, these
        contacts would not contain the reg-id Contact header field
        parameter.  The proxy MUST select the most recently refreshed
        contact.  As with draft-ietf-sip-outbound, if a request to this
        target fails with a 408 (Request Timeout) or 430 (Flow Failed)
        response, the proxy SHOULD retry with the next most recently
        refreshed contact.  Furthermore, if the request fails with any
        other response, the proxy MUST NOT retry on any other contacts
        for this instance.

> I believe: It gets routed on the flow that formed the dialog, as long as 
> that flow exists. The proxy has stored dialog state and knows which flow 
> the dialog-forming request used.
> 
> The GRUU spec assumes one contact per gruu. Outbound transforms this to 
> multiple contacts and multiple flows per gruu. I think this requires 
> further specification as to flow selection, possibly for out-of-dialog 
> messages and almost definitely for in-dialog messages. Perhaps this is 
> documented somewhere and I've just missed it.
> 
> Any clues?
> 
> -- 
> Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 18 Oct 2008 00:31:44 +0200

(An informational note from one of the WG co-chairs)

This document is not about to go to the RFC editor's for publishing.

It is about to go to the IETF to see if they agree it, i.e. the SIP WG
have submitted a publication request.

That means it still gets reviewed by:

Our AD
The security directorate
The GEN ART review team
Any other review teams that think they have a hand in this
IANA
The IETF as a whole (and that definitely does include you unless you
explicitly exclude yourself)
The IESG as a whole

Once that has happened, the world just may let the RFC editors get their
hands on it.

I am sure somewhere in that process you can get to make any comments you
think relevant - as I believe I have said before.

And I would note that at the moment I have see any proposal that adds
more than about 4 lines of text to outbound, and no other issues that
are so far looking like they achieve consensus that there is an issue.
On that basis there are many many more documents that score lower in
their readiness for publication request - and I note that none of this
current discussion got raised by you until we had completed at least two
WGLC and at least two requests to see if we were ready for the
publication request. 

So yes carry on making comments, but lets look to start building some
consensus from the responses.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juha Heinanen
> Sent: Friday, October 17, 2008 6:00 PM
> To: Dean Willis
> Cc: SIP IETF
> Subject: [Sip] Outbound and mid-dialog requests with GRUU
> 
> Dean Willis writes:
> 
>  > Any clues?
> 
> it is very revealing that at the stage when these i-d are 
> about to go to rfc editors for publishing, there is lots of 
> all kind of issues that even the experts are not sure about.
> 
> even if these issues finally get sorted out on the list, 
> there is absolutely no chance whatsoever that an average 
> implementer who has not participated in these discussions 
> could even get his/her implementation correct.  these 
> specifications are far too complicated for that.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 18:46:32 -0500

> even the experts are not sure about.

Huh. I figure that I'm usually the last to understand something; by  
the time I understand it, it should be obvious to everybody. I still  
don't understand SDP.

> correct.  these specifications are far too complicated for that.

You're right. I think we should close the working group and ban all  
authors from publishing for  a year. That'll teach us!

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 19:02:48 -0500

On Oct 17, 2008, at 12:21 PM, Paul Kyzivat wrote:

>
>
> Dean Willis wrote:
>> Here's a question:
>> A UA has registered two flows to one instance. It has one gruu. The  
>> UA uses the gruu as the contact in a dialog-forming request.

Not helpful; section 7 refers to out-of-dialog request forwarding.

What happens to in-dialog requests?

The request references a gruu.

A pre-outbound gruu is bound to one and only one contact, so the  
request-URI transformation rule is obvious; transform the request-URI  
using the contact associated with the gruu. This behavior is specified  
in 6.1 of the gruu draft. Oddly enough, that text in gruu-6.1 replaces  
the request-URI with "the registered contacts" (note the plural). Not  
sure that makes sense. Somebody tell me if that's a bug in gruu.

An outbound-compliant gruu is bound to one and only instance, but an  
instance can have multiple contacts.

I think what has to happen to make it work is fairly obvious, but it  
isn't documented anywhere I can find.

There's some hinting at it in outbound-5.3.2, but inly from the  
perspective of the edge proxy. What has to happen at the home proxy to  
make this work?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Oct 2008 20:50:25 -0400

> Not helpful; section 7 refers to out-of-dialog request forwarding.

Why do you say that. That section of outbound doesn't even mention dialogs.

> perspective of the edge proxy. What has to happen at the home proxy to 

I assume the same thing as for out of dialog requests. Out of dialog 
requests that reference a gruu need just as much to get to the proper 
instance as in-dialog requests do.

Why does it matter if both flows are functional? Presumably if one of 
the flows has had problems the proxy ought to choose the other one first.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 20:18:24 -0500

> Why do you say that. That section of outbound doesn't even mention  

It also doesn't mention multiple contacts per GRUU.

>> request-URI transformation rule is obvious; transform the request- 
>> URI using the contact associated with the gruu. This behavior is  
>> specified in 6.1 of the gruu draft. Oddly enough, that text in  
>> gruu-6.1 replaces the request-URI with "the registered  
>> contacts" (note the plural). Not sure that makes sense. Somebody  
>> tell me if that's a bug in gruu.
>> An outbound-compliant gruu is bound to one and only instance, but  
>> an instance can have multiple contacts.
>> I think what has to happen to make it work is fairly obvious, but  
>> it isn't documented anywhere I can find.
>> perspective of the edge proxy. What has to happen at the home proxy  
>> to make this work?
>
> requests that reference a gruu need just as much to get to the  
> proper instance as in-dialog requests do.

Not really; for out-of-dialog requests, any contact is equally valid.  
But for in-dialog requests, I think there's a need to use the flow  
that was used by the earlier requests in the dialog, if that's possible.

>
>
> Why does it matter if both flows are functional? Presumably if one  
> of the flows has had problems the proxy ought to choose the other  
> one first.

Are there any SIP devices that get confused when they see an  
unexpected request URI on a request, for example, when the request URI  
spontaneously changes mid-dialog without a reINVITE?

Are there other elements that might get confused by NOT seeing some  
messages in a dialog?

For example: what happens if there is an off-the-shelf SBC squatting  
on each flow?

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 18 Oct 2008 09:14:54 +0300

> authors from publishing for  a year. That'll teach us!

exactly and better yet, start implementing what has been published or
about to be published.  when all specs have been implemented by the
authors and interoperability has been verified, the gw can resume its
work.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Oct 2008 10:51:28 -0400

comment at end.

Dean Willis wrote:
>>> using the contact associated with the gruu. This behavior is 
>>> gruu-6.1 replaces the request-URI with "the registered contacts" 
>>> (note the plural). Not sure that makes sense. Somebody tell me if 
>>> that's a bug in gruu.
> But for in-dialog requests, I think there's a need to use the flow that 
> was used by the earlier requests in the dialog, if that's possible.
> 
>>
>>
> Are there any SIP devices that get confused when they see an unexpected 
> request URI on a request, for example, when the request URI 
> For example: what happens if there is an off-the-shelf SBC squatting on 
> each flow?

Well, the multiple flows are there for redundancy, right?
If one of the flows failsl, the whole point is that things should 
continue. If the UA gets upset receiving in-dialog messages on a 
different flow, then things aren't working right.

	Thanks,
	Paul

---

From: "Orsic, Milo \(Milo\)" <[email-masked]>
Date: Sat, 18 Oct 2008 12:17:14 -0500

Hi Dean,
Pertaining to Paul's posting below:
------------------------------ 
Well, the multiple flows are there for redundancy, right?
If one of the flows fails, the whole point is that things should
continue. If the UA gets upset receiving in-dialog messages on a
different flow, then things aren't working right.

Thanks,
Paul
======================

The UA will not get upset, since it may not receive the message. Assume:

1. First registration between (UA's address) IP#1 via edge proxy#1
establishes the binding in the NAT/reflexive-firewall (and flow#1) - as
required by the draft.

2. Second registration between (UA's address) IP#2 via edge proxy#2 is
used for redundancy, establishes the binding in the
NAT/reflexive-firewall (and flow#2) - as required by the draft.

3. Dialog is established using this flow#1 (and Route for this dialog
includes the edge proxy#1).

There was never a registration between IP#2 via proxy#1. Hence, any
in-dialog request (destined for the UA) sent from edge proxy#1 (since it
is in the Route) to IP#2 will be filtered by the NAT/reflexive-firewall.

As you can see by this example, the second registration - as required by
the draft - doesn't really creates a redundant flow.  
IMHO, the draft should restrict the "redundancy" to a single contact
address (reached via different edge proxies).

Cheers,
Milo 
========================================================================
====
========================================================================
=== 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Saturday, October 18, 2008 9:51 AM
To: Dean Willis
Cc: SIP IETF
Subject: Re: [Sip] Outbound and mid-dialog requests with GRUU

comment at end.

Dean Willis wrote:
>>> request-URI transformation rule is obvious; transform the 
>>> request-URI using the contact associated with the gruu. This 
>>> behavior is specified in 6.1 of the gruu draft. Oddly enough, that 
>>> text in

	Thanks,
	Paul
_______________________________________________
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
_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sun, 19 Oct 2008 12:38:48 -0500

> different flow, then things aren't working right.

Fair enough. Perhaps a simple statement of this potential, and a  
requirement for supporting this eventuality as a consequence of  
supporting the outbound extension, could be added to the Outbound spec?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 19 Oct 2008 12:47:21 -0500

On Oct 18, 2008, at 12:17 PM, Orsic, Milo (Milo) wrote:

> establishes the binding in the NAT/reflexive-firewall (and flow#1) -  
> as required by the draft.
>
> 2. Second registration between (UA's address) IP#2 via edge proxy#2  
> is used for redundancy, establishes the binding in the NAT/reflexive- 
> firewall (and flow#2) - as required by the draft.
>
> 3. Dialog is established using this flow#1 (and Route for this  
> dialog includes the edge proxy#1).
>
> in-dialog request (destined for the UA) sent from edge proxy#1  
> (since it is in the Route) to IP#2 will be filtered by the NAT/ 
> reflexive-firewall.
>
> As you can see by this example, the second registration - as  
> required by the draft - doesn't really creates a redundant flow.
>

Flow 1 goes from contact 1 through edge proxy 1, flow 2 goes from  
contact 2 through edge proxy 2. Both flows are attached to a single  
instance-id. The home proxy/registrar  keeps track of the keepalive  
status of each flow, and the keepalives keep the NAT binding open for  
each flow.

Presume flow 1 is in-use for a dialog, and the flow fails. The home  
proxy must then re-route the dialog to flow 2. This requires a fair  
bit of mechanism in the proxy, mechanism that is not completely  
defined in the outbound draft, but that can be readily inferred.

Another way to look at it is that Outbound routes to the "instance",  
not to the "contact".

I think there is a little bit of confusion about gruu. Without  
Outbound, the gruu is an alias for the conact. With Outbound, Is the  
gruu an alias for the contact or the instance ?  From a semantic- 
clarity model, I think gruu needs to be an alias for the instance.  
This however, is not completely clear to me in the current spec set.

--
Dean

---

From: "Orsic, Milo \(Milo\)" <[email-masked]>
Date: Sun, 19 Oct 2008 18:24:24 -0500

Hi Dean,
Thank you for your response. In the text below, I am not referring to
GRUU, i.e. I am referring to outbound. IMHO there are two cases, i.e.:

1. The initial dialog-forming request, destined to the UA. When this
request arrives at the authorative proxy, the outbound mechanism works
OK (i.e. there are two-or-more alternative routes to the target UA which
will be tried sequentially); and

2. The case when the dialog has been established. In this case the
far-end UA builds the Route header that it will include in its
subsequent in-dialog requests. Unfortunately, this Route header includes
the edge-proxy#1 and flow#1 (flow-token#1). The failure of the flow#1
can not be tried again via flow#2. For the the authorative proxy, to
re-write the Route header (to replace the edge-proxy#1 with
edge-proxy#2) for this request and all subsequent in-dialog requests
(destined for the UA) violate the SIP proxy function. Hence, I have my
doubts that the outbound "alternative flow mechanism" will work for the
in-dialog requests - as I have stated in my email.

Cheers,
Milo 

=====

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Sunday, October 19, 2008 12:47 PM
To: Orsic, Milo (Milo)
Cc: Paul Kyzivat; SIP IETF
Subject: Re: [Sip] Outbound and mid-dialog requests with GRUU

> used for redundancy, establishes the binding in the NAT/reflexive- 
> in-dialog request (destined for the UA) sent from edge proxy#1 (since 
> it is in the Route) to IP#2 will be filtered by the NAT/ 
> reflexive-firewall.
>
> As you can see by this example, the second registration - as required 
> by the draft - doesn't really creates a redundant flow.
>

--
Dean