[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Outbound-05: Registrar checking all Path headers for "ob" (was: "RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxyneedto support outbound?")



 
Hi Rohan,

Chapter 6 of outbound-05 still says that the registrar shall check ALL
Path headers for the "ob" URI parameter, eventhough I think we agreed
it's enough to only check the Path of the edge proxy.

Or, is there a reason why all proxies in the path must insert Path with
"ob"?

Regards,

Christer


> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:christer.holmberg at ericsson.com] 
> Sent: 14. elokuuta 2006 13:39
> To: Rohan Mahy
> Cc: IETF SIP List
> Subject: RE: [Sip] Outbound issues: slides 9 and 10 - Why 
> does every proxyneedto support outbound?
> 
> 
> Hi Rohan, 
> 
> >>>Christer, please read the slides.  The issue we are trying 
> to detect 
> >>>is described in slide 9.  The UA sends through an 
> outbound-proxy that 
> >>>adds a Path, but does not support outbound.  The registrar 
> needs to 
> >>>detect that.
> >>
> >>I am not arguing against that. I am simply commenting on 
> the proposed 
> >>mechanisms that YOU wrote.
> >>
> >>YOU said that ALL Path headers (not only the one inserted by the 
> >>outbound proxy) must contain the ob parameter, and I question that.
> >>
> >>YOU said that the registrar must start comparing Vias with 
> Paths, and 
> >>I propose a way to avoid that.
> >
> >Right.  You should be able to compare only the first Path 
> and the first
> Via.  I guess there is no reason for the other Path headers 
> to have ;ob.
> 
> Wouldn't it be easier, and "cleaner", to say that the 
> outbound proxy MUST always (no matter what domain it belongs 
> to) Path with "ob"?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> > On Aug 9, 2006, at 9:46, Christer Holmberg ((JO/LMF)) wrote:
> >>
> >> Hi,
> >>
> >> A couple of questions:
> >>
> >>> The issues on slide 9 (how does a registrar verify that an edge 
> >>> proxy
> >> supports outbound) and slide 10 (what does >"Supported: outbound"
> >> mean) deal with detecting that all the required hops support
> outbound.
> >
> >> Slide
> >>> 9 specifically uncovered a problem with outbound proxies 
> that add a
> >> Path URI but don't include a flow token.
> >>>
> >>> The proposed solution is as follows.  If a proxy inserts a Path 
> >>> header
> >> with a flow token consistent with the rules d
> >>> escribed in outbound, it MUST add the ;ob parameter to 
> the proxy URI
> >> that has the flow token.
> >>>
> >>> The registrar verifies that any Path header URIs contain the ;ob
> >> parameter.  If there are any Path URIs without the ob
> >>> parameter, the registrar does not return Supported: outbound.
> >>
> >> [CHH] Why would every Path header need to contain the ;ob 
> parameter?
> >> The
> >> REGISTER request may traverse, in addition to the outbound proxy, 
> >> multiple proxies which insert a Path header. Do all these proxies 
> >> really need to support outbound?
> >>
> >>> Furthermore, the registrar needs to check that the first 
> hop after 
> >>> the
> >> UAC is represented in the Path list (unless the
> >>> registrar recognizes that the first hop after the UAC is 
> in the same
> >> domain and doesn't need to include Path URIs with a
> >>> flow token).  Note that this implies that whatever the 
> proxy puts in
> >> the Via (IP address or FQDN), it must put the same
> >>> hostname in the Path header (but there is no need for a 
> complete URI
> >> comparison).  If the first hop is not correctly
> >>> represented, the registrar ignores the reg-id parameter 
> and does not
> >> return Supported: outbound.
> >>
> >> [CHH] Isn't it much easier to mandate the outbound proxy to always 
> >> insert a Path header?
> >>
> >> OR, another possibility is that the outbound proxy, if it detects 
> >> that
> >
> >> the UAC supports outbound, insert some option-tag of itself in the 
> >> Supported header, to indicate to the registrar that it supports 
> >> outbound. Then the registrar does not need start looking 
> at the Path 
> >> headers.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> The implication of this is that an outbound-proxy that supports 
> >> outbound needs to support Path and flow tokens for 
> registrations to 
> >> all foreign domains.  Inside the same domain, the 
> first-hop proxy and
> 
> >> the registrar can still use Path to communicate with each 
> other, but 
> >> they can use some other private mechanism to disaggregate this 
> >> functionality.
> >>
> >> thanks,
> >> -rohan
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use 
> >> sip-implementors at cs.columbia.edu for questions on current sip Use 
> >> sipping at ietf.org for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> sip-implementors at cs.columbia.edu for questions on current sip 
> Use sipping at ietf.org for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> sip-implementors at cs.columbia.edu for questions on current sip 
> Use sipping at ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip