[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxyneed to 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