Re: [Sip] outbound open issues from IETF 67

["Rohan Mahy" <[e-mail]>]

On 11/21/06, [e-mail] <[e-mail]> wrote:
>
> 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.

Correct.

thanks,
-rohan


> 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