Subject: [Sip] outbound open issues from IETF 67

From: Rohan Mahy <[email-masked]>
Date: Mon, 20 Nov 2006 11:20:40 -0800 (PST)

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: <[email-masked]>
Date: Tue, 21 Nov 2006 17:11:04 +0200

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:[email-masked]] 
>Sent: 20.November.2006 21:21
>To: [email-masked]
>Cc: Rohan Mahy
>Subject: [Sip] outbound open issues from IETF 67
>
>Hi Folks,
>
>make language fuzzy to save token which points to a 'logical 
>flow' that is

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 21 Nov 2006 11:51:50 -0800

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

---

From: <[email-masked]>
Date: Wed, 22 Nov 2006 09:44:43 +0200

Hi Rohan,

>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

>From: ext Rohan Mahy [mailto:[email-masked]] 
>Sent: 21.November.2006 21:52
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Sip] outbound open issues from IETF 67
>
>Hi Erkki,
>

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 22 Nov 2006 10:38:26 -0800

On 11/21/06, [email-masked] <[email-masked]> wrote:
> outbound it finds out that it will not be able to try multiple registrations.

Correct.

thanks,
-rohan

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Nov 2006 16:01:59 +0100

They, in this case, is I believe one organisation.

The proposal was referred back until the requirements are known - in any
case 3GPP cannot define option-tags.

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 21 November 2006 15:11
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] outbound open issues from IETF 67
> 
> 
> Hi Rohan,
> 
> 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.
> * 3GPP wants separation of binding behavior and flow-token behavior
> >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:
> >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
> >
> 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.
> >
> >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.
> >
> >This list is for NEW development of the core SIP Protocol Use 
> >[email-masked] for questions on current sip Use 
> >[email-masked] for new developments on the application of sip
> >
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip