RE: [Sip] outbound open issues from IETF 67

[<[e-mail]>]

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