RE: GRUU support in reg event package
<hisham.khartabil <at> nokia.com>
2004-10-05 23:44:06 GMT
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> Sent: 06.October.2004 00:01
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: sipping <at> ietf.org
> Subject: Re: [Sipping] GRUU support in reg event package
>
>
> Hisham,
>
> I realized I never responded to your points here.
>
> Paul
>
> hisham.khartabil <at> nokia.com 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:alice <at> atlanta.com,
> and the contact is sip:alice <at> alice-pc.private.atlanta.com,
> 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:alice <at> alice-pc.private.atlanta.com
> 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
RSS Feed