Subject: [Sipping] RE: Comment on GRUU requirements

From: Adam Roach <[email-masked]>
Date: Tue, 29 Jul 2003 12:52:25 -0500

Jonathan Rosenberg [mailto:[email-masked]] writes:
 
> I do agree we need to hand out GRUUs. I don't think its a URI
> parameter. I think that it would be contextual. We definitely
> need to be able to hand them out between peers in a dialog, 
> in which case a new header could be used to carry them.

That addresses precisely the problem I was trying to solve.

/a

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Tue, 29 Jul 2003 14:11:22 -0500

Arjun Roychowdhury [mailto:[email-masked]] writes:

> 1. Why does the peer need to know a URI is a GRUU or not ? 
> (stated both in 
> Adam's mail below as well as REQ-8 in the draft).

I believe you need to re-read my earlier mail and Jonathan's
draft a bit more closely. The stated reason for needing to do
this is so that once I am in a dialog, I can send an out-of-
dialog request guaranteed to be received by the same UA that
the dialog connects me to.

/a

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 29 Jul 2003 15:36:23 -0400

Yes, I did read that point.

Let me re-phrase : 

If a UA wanted to be globablly reachable, is it enough for it to make sure 
the URI it advertises is a GRUU as opposed
to the sender wanting to know if it really is a GRUU ?

Instead of the sender "wanting to make sure that any out-of-band message 
it sends goes to the same UA that the dialog connects it to'
can't the owner of the URI take this decision - ie 'if I want to be 
reached at the same UA then I would respond , say in Contact, with
a GRUU. Its not upto the peer to reach me at my instance, its upto me to 
allow that if I want'

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 

Adam Roach <[email-masked]>
Sent by: [email-masked]
07/29/2003 03:11 PM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        RE: [Sipping] Re: Comment on GRUU requirements

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 29 Jul 2003 16:40:45 -0500

Yes, the UA can make a choice as to whether it
advertises such a URI.

However, the sender of a request frequently needs to
know whether an advertised URI has GRUU properties.
Many requests would make no sense otherwise.

Currently, the only way that SIP allows requestors
to ensure this property is by sending the request
in an existing dialog. This is why we have the
ability, in RFC 3265, to share dialogs between
SUBSCRIBE requests and INVITE requests. The problem
is that doing so is very awkward, and creates quite
a few subtle issues.

On the other hand, if we had GRUUs exchanged during
call setup, we could forgo this silliness altogether.
Admittedly, it's a bit late for SUB/NOT (although I
would like to move towards deprecating this behavior
at some point), but that doesn't mean that the next 
time we need this property that we should go down
the path of dialog reuse.

/a

P.S. Copying sipping-admin on these messages is completely
     pointless, since the chairs undoubtedly subscribe to
     the mailing list. It is also, I'm certain, annoying 
     for Rohan, Dean, and Gonzalo.

> -----Original Message-----
> From: Arjun Roychowdhury [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2003 14:36
> To: Adam Roach
> Cc: [email-masked]'; [email-masked]

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 29 Jul 2003 19:22:28 -0400

ARC> Valid point. I would like to hear about how (if at all) the GRUUs 
affect routing policies at the proxy (my first set of Qs).

ARC> Well, pointless or not, I dont insert 'sipping-admin' because I love 
that ID. It seems if you hit a reply-all with history for a mail that has 
a 'Sender:sipping-admin@xxx' (the case when
the mail reflector sends the mail out), lotus notes inserts that id into 
the cc list. I wonder
if the sender: field can be modified to have the list it to avoid this 
problem.