Subject: Re: [Sip] GRUU and Mid-Dialog Requests

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 31 Aug 2006 14:56:53 +0200

>> Let's say UA X has a regular AOR (AOR-X), and 2 GRUU AOR 
>> (AOR-X;gruu=111 and AOR-X;gruu=222).

> The above is a little confusing, because I had assumed "UA X" 
> referred to a user agent

I agree, I should have said that a "user X" has a regular AOR and 2 GRUU 
AOR.

> Updating the To header is currently not allowed.

Yes I know it is not currently allowed to update the To URI in the INVITE's 
response and that an additional UDPATE request is suggested for that. 
However, I've never really understood why updating the "To" directly in the 
response is not acceptable, even when I look at the minutes of ietf66 
(topic "connected identity", slide 6).

> It would be helpful if you would send an example, 
> containing the messages and headers that you propose using.

Basically, what I mean is that a "GRUU" should be an AOR (which is used for 
routing initial-requests that will reach a contact through a resolution at 
the home proxy) and should not a remote-target (which is for mid-dialogs 
requests). 
I have depicted an illustrative call flow at the end of the mail: flows (3) 
and (4) are new, the URI in the To header field is updated in (7).(I'm 
aware that this would also have additional consequences on the 
registration/proxying steps.)

> BUT, the gruu proposal has been baking for a long time, so this is kind 
of late to consider a major change.

I did not realize this point when reviewing the previous draft versions, I 
admit I only realized this point lately. If there's a rough consensus with 
the current solution, let's forget it.

Xavier

     Caller                 Proxy                Callee
       |                     |(1) REGISTER         |
       |                     |<--------------------|
       |                     |(2) 200 OK           |
       |                     |-------------------->|
       |                     |(3) REGISTER         |
       |                     |<--------------------|
       |                     |(4) 200 OK           |
       |                     |-------------------->|
       |(5) INVITE           |                     |
       |-------------------->|                     |
       |                     |(6) INVITE           |
       |                     |-------------------->|
       |                     |(7) 200 OK           |
       |                     |<--------------------|
       |(8) 200 OK           |                     |
       |<--------------------|                     |
       |(9) ACK              |                     |
       |-------------------->|                     |
       |                     |(10) ACK             |
       |                     |-------------------->|
       |(11) SUBSCRIBE       |                     |
       |-------------------->|                     |

(1)
REGISTER sip:example.com SIP/2.0
Supported: gruu
To: Callee <sip:[email-masked]>
<allOneLine>
Contact: <sip:[email-masked]>;
+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
</allOneLine>

(2)
SIP/2.0 200 OK
To: Callee <sip:[email-masked]>;tag=b88sn
<allOneLine>
Contact: <sip:[email-masked]>;
  gruu="sip:[email-masked];gruu;
  opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
  ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>";
  expires=3600
</allOneLine>
Content-Length: 0

(3)
REGISTER sip:example.com SIP/2.0
Require: gruu
<allOneLine>
To: Callee <sip:[email-masked];gruu;
  opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Contact: <sip:[email-masked]>;expires=3600

(4)
SIP/2.0 200 OK
<allOneLine>
To: Callee <sip:[email-masked];gruu;
  opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
</allOneLine>
Contact: <sip:[email-masked]>;expires=3600

(7)
SIP/2.0 200 OK
From: Caller <sip:[email-masked]>;tag=n88ah
<allOneLine>
To: Callee <sip:[email-masked];gruu;
  opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
  grid=99a>;tag=a0z8
</allOneLine>
CSeq: 1 INVITE
Supported: gruu
Contact: <sip:[email-masked]>;

(11)
<allOneLine>
SUBSCRIBE sip:[email-masked];gruu;
  opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
  grid=99a SIP/2.0
</allOneLine>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK9zz8
From: Caller <sip:[email-masked]>;tag=kkaz-
<allOneLine>
To: <sip:[email-masked];gruu;
  opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
  grid=99a>
</allOneLine>
Supported: gruu

_______________________________________________
Sip mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Aug 2006 11:52:13 -0400

> (topic "connected identity", slide 6).

Well, that is a separate discussion. For the moment we can discuss what 
you are proposing with the understanding that it assumes the To URI can 
be changed in the response.

> registration/proxying steps.)

You don't show it, but I am assuming that (5) and (6) have

	To: Callee <sip:[email-masked]

and that it is changed by the callee for message 7. Is that right?

And then Caller is expected to consider the To URI in the response to be 
both the "connected party" and device-specific URI for future requests?

In that case, the caller will need some rules for how to use that 
To-URI. What if it wants to present the identity to its user, or save it 
in a call log for future callback? Does it strip off the opaque parameter?

Assuming that caller also has a gruu, wouldn't it then need to use that 
as the From-URI in (5) and (7).

I think this proposal mixes up a lot of different things.

	Paul