RE: [Sip] outbound open issues from IETF 67

[<[e-mail]>]

 
Hi Rohan,

Just to verify that I understood your answer correctly:

>If the first hop edge proxy (the P-CSCF) doesn't support outbound, it
>will not add the 'ob' parameter to the Path header, so the registrar
>will ignore the reg-id parameter in the request.

... and when the registrar ignores the reg-id within REGISTER it will
not add the Supported: outbound header to the 200 OK response.
And when the UA finds that the 200 OK does not contain Supported:
outbound
it finds out that it will not be able to try multiple registrations.

Please tell if you meant this or something different.

Thanks,

Erkki

>-----Original Message-----
>From: ext Rohan Mahy [mailto:[e-mail]] 
>Sent: 21.November.2006 21:52
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [e-mail]; [e-mail]
>Subject: Re: [Sip] outbound open issues from IETF 67
>
>Hi Erkki,
>
>If the first hop edge proxy (the P-CSCF) doesn't support outbound, it
>will not add the 'ob' parameter to the Path header, so the registrar
>will ignore the reg-id parameter in the request.
>
>hope this helps.
>thanks,
>-rohan
>
>On 11/21/06, [e-mail] 
><[e-mail]> wrote:
>>
>> Hi Rohan,
>>
>> I do not have any objections to any of the proposals you made
>> for Outbound. However I have a question related to the Issue 3G
>> you had on your slideset. The slideset outlined the 3GPP requirement
>> as follows:
>>
>> - 3GPP and others want to store multiple path vectors back to an
>> instance, each associated with a reg-id.
>> - New registrations with the same reg-id would replace the 
>old binding.
>> * BUT 3GPP wants to do this unrelated to outbound flow-token
>> processing
>> * 3GPP wants separation of binding behavior and flow-token
>> behavior
>> * Why? Their IPsec UDP uses several pairs of actual flows,
>> instead of just one.
>>
>> In 3GPP there is also a backwards compatibility issue related
>> to the IPSec SA management in the edge proxy (P-CSCF). Old
>> implementations not supporting Outbound would drop the old
>> logical flow (IPSec SA) if the UA registers with a new reg-id
>> and IP address. Thus the UA should be able to make sure that
>> the edge proxy supports the new behaviour, before trying to
>> establish multiple flows over different access networks
>> towards the single edge proxy.
>>
>> They have been proposing a new option tag for this purpose,
>> something like this:
>>
>>    Name: mreg
>>    Description: This option-tag is used to identify SIP servers which
>>       are able to maintain multiple logical flows per UA instance.
>>
>> What do you think about this proposal ?
>>
>> Regards,
>>
>> Erkki
>>
>> >-----Original Message-----
>> >From: ext Rohan Mahy [mailto:[e-mail]]
>> >Sent: 20.November.2006 21:21
>> >To: [e-mail]
>> >Cc: Rohan Mahy
>> >Subject: [Sip] outbound open issues from IETF 67
>> >
>> >Hi Folks,
>> >
>> >I've incorporated all the changes we agreed to at IETF67.  For
>> >those who
>> >have not seen them yet, please consult the slides available here:
>> >http://www3.ietf.org/proceedings/06nov/slides/sip-3.pdf
>> >
>> >In addition, I have proposed text for Issues D&E (see below).
>> >
>> >In summary, we agreed from the meeting:
>> >- Consensus to use 430 response
>> >- Consensus to keep the "stable flow timer"
>> >Bug A: No objection to fixing this bug
>> >Issue B: consensus to only require 1st hop and registrar to 
>participate
>> >Issue C: consensus for No Action
>> >Issue D: did not discuss, proposal mentioned below
>> >Issue E: did not discuss, proposal mentioned below
>> >Issue F: consensus for No Action
>> >Issue 3G: rough consensus to Accept action 2
>> >
>> >(Bug A): Provided mention of the 'rport' parameter.
>> >
>> >(Issue 3G): Relaxed flow-token language slightly. Instead 
>of flow-token
>> >saving specific UDP address/port tuples over which the 
>request arrived,
>> >make language fuzzy to save token which points to a 'logical
>> >flow' that is
>> >known to deliver data to that specific UA instance.
>> >
>> >(Issue B): Changed registrar verification so that only
>> >first-hop proxy and
>> >the registrar need to support outbound.  Other intermediaries
>> >in between
>> >do not any more.
>> >
>> >(Issues D&E): Proposal text:
>> >The UAC can situationally decide whether to request outbound
>> >behavior by
>> >including or omitting the 'reg-id' parameter.  For example, 
>imagine the
>> >outbound-proxy-set contains two proxies in different domains,
>> >EP1 and EP2.
>> > If an outbound-style registration succeeded for a flow
>> >through EP1, the
>> >UA might decide to include 'outbound' in its option-tag when
>> >registering
>> >with EP2, in order to insure consistency.  Similarly, if the
>> >registration
>> >through EP1 did not support outbound, the UA might decide 
>to omit the
>> >'reg-id' parameter when registering with EP2.
>> >
>> >I believe the proposed text for D&E is sufficient and 
>should be fairly
>> >non-controversial.  If anyone has any objections, please 
>speak up ASAP
>> >(and *send text* ;-).
>> >
>> >thanks,
>> >-rohan
>> >
>> >
>> >_______________________________________________
>> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> >This list is for NEW development of the core SIP Protocol
>> >Use [e-mail] for questions on current sip
>> >Use [e-mail] 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 [e-mail] for questions on current sip
>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip