Subject: RE: [Sipping] GRUU support in reg event package

From: [email-masked]
Date: Wed, 6 Oct 2004 02:44:06 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 06.October.2004 00:01
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Sipping] GRUU support in reg event package
> 
> 
> Hisham,
> 
> I realized I never responded to your points here.
> 
> 	Paul
> 
> [email-masked] wrote:
> > 
> >>Jonathan has expressed interest in including info on any 
> Path header 
> >>that might be associated with a Contact.
> >>
> >>- Do you think info on the Path header should be returned
> >>   in reg event notifications?
> > 
> > Well, the Path header contents are useless to the client. I 
> don't know what advantages this will gather.
> 
> There is potential use for this by a client, although 
> unnecessary when 
> gruus are available.
> 
> If one uses the reg event package to learn about 
> registrations, and if 
> this provided Path header info, then that could be used to format a 
> request so it traverses the same path that a request addressed to the 
> AOR would, but supplying the contact address rather than 
> having the home 
> proxy pick it. This would permit reaching a contacts that 
> isn't directly 
> reachable from the sender.
> 
> Suppose the AOR is sip:[email-masked],
> and the contact is sip:[email-masked],
> and there is an associated Path with sip:sbc.atlanta.com;lr
> 
> Then a subscriber could use this information to format a request like:
> 
> 	INVITE sip:[email-masked]
> 	Route: sip:atlanta.com;lr
> 	Route: sip:sbc.atlanta.com;lr
> 	...

This is a stretch, since I doubt that anyone besides the owner would subscribe or should be allowed to such event package. Path headers reveal information about the network architecture. That may be a security problem.

/Hisham

> 
> This would have a decent chance of actually making it to Alice's pc.
> (Admittedly this is a stretch, and there are other ways to 
> achieve the 
> same thing.)
> 
> >>At them moment I am not aware of any other registrar state to be 
> >>reported, but feel free to point out something I have forgotten.
> >>
> >>- Are there other extensions to the reg event package that 
> you would 
> >>like to see?
> > 
> > Maybe service-route header? More useful to the client that 
> the Path headers anyway.
> 
> The service-route is only useful to the register client, and 
> is provided 
> to it via the register. This client doesn't need to subscribe 
> to the reg 
> event package to get this information. And the information 
> isn't useful 
> to any other client.
> 
> So I find reporting on Path at least potentially useful, 
> while reporting 
> on Service-Route doesn't seem to be.
> 
> > I have a further comment about this draft:
> > 
> > I think it is a good idea for the draft stress that this is 
> an extension and how a client should behave when it receives 
> the notifications with XML elements it does not understand 
> (ignore them, for example). A section on registrar behaviour 
> is beneficial as well.
> 
> OK, that seems reasonable.
> 
> 	Thanks,
> 	Paul
> 
> 

_______________________________________________
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: Wed, 06 Oct 2004 09:24:57 -0400

[email-masked] wrote:
>>unnecessary when gruus are available.
>>

Yes, it is true that not everybody is likely to be permitted to 
subscribe to this package. But the "owner" also includes agents working 
on behalf of the owner, and there may be several of these.

For instance, *all* the devices that register are agents of the owner. 
These act as "multiple line appearances" where the AOR is the "line". To 
provide the kind of user experience that is normally expected for 
multiple line appearances, each device needs to be aware of all the 
others and subscribe to the dialog event package at each of its peers. 
The 'reg' package is the most reliable way keep current about which 
peers exist.

And once a peer is discovered, a subscribe must be directed to that 
peer. The above is one way to achieve that.

Of course GRUU provides another way, and that is the counter-argument.

Another possible use case is when the "home proxy" is not collocated 
with the registrar. It may be that the proxy itself wants to use the reg 
event package to maintain its routing tables.

	Paul