Re: [Sip] outbound open issues from IETF 67

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

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