Subject: [Sip] New Path Extension Header Draft

From: "Dean Willis" <[email-masked]>
Date: Wed, 6 Feb 2002 23:49:01 -0600

I've cobbled together a rough draft of a Path header extension in an attempt to meet the a requirement for service route discovery during REGISTER for 3GPP established in the Garcia 3GPP requirements draft in the SIPPING group.

It will be announced on internet-drafts soon, and you can pull from:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt

---

From: Aymeric MOIZARD <[email-masked]>
Date: Thu, 07 Feb 2002 14:56:59 +0100

Is there any update for this draft for bis-06 or bis-07?

I notice that in section 7.5 (INVITE with inconsistent Accept
and message body), the SDP message does not have any "o=" line....

Aymeric

_______________________________________________
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: Aymeric MOIZARD <[email-masked]>
Date: Thu, 07 Feb 2002 15:16:06 +0100

Also, many SDP messages does not contains any "t=" line
This is true from section 7.1 to section 7.19

---

From: Alan Johnston <[email-masked]>
Date: Thu, 07 Feb 2002 08:38:08 -0600

Aymeric,

Thanks for the comments - we'll make the changes.  We are working on an
update to the document - it will be released shortly.

The major changes will be adding From tags, branch IDs, Max-Forwards,
and updating Record-Route behavior to bring it in line with recent
changes to bis.  We'll also be going through all the test messages with
a fine tooth comb as well.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Aymeric MOIZARD
> Sent: Thursday, February 07, 2002 8:16 AM
> To: [email-masked]
> Subject: Re: [Sip] draft-ietf-sip-call-flows-05.txt
> 
> 
> > I notice that in section 7.5 (INVITE with inconsistent Accept and 
> > message body), the SDP message does not have any "o=" line....
> > 
> > Aymeric
> > 
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Feb 2002 09:58:24 -0500

Dean,

Thanks for pulling this together....

Some comments.

1. The example messages are screwed up, looks like a CRLF was lost at
the end of each line.

2. I think the mechanism you have here differs in a subtle, but
important way from Record-Route. By my reading, the registrar does *not*
return the received path headers in the 2xx response. Rather, proxies
must explicitly insert the path in both the request and the response if
they wish to be present in both directions. I think this is very much
the right thing to do (I am not sure what 3gpp has done here). 

In the general case, the problem is really that P2 does not know about
P1, and so cannot delivery incoming calls towards UA1 without learning
about P1, through a registration. That is the primary function that Path
needs to satisfy. Now, interestingly, there is no corresponding
discovery problem, in the general case, for requests from UA1 out. UA1
already knows about P1 and P2; it does not need to discover them through
Path in order to construct the forward route set. Indeed, the only
reason why a forward request would need to have a route set learned from
register, is if there were elements that created state whose lifetime
was equal to that of the registration state. In this case, those
specific elements would need to be on the path of subsequent register's
in order to properly maintain that state (and, more importantly, expire
it). 

This is the case for 3gpp, where the forward path effectively stores the
state associated with the selection of the S-CSCF. However, that is not
a general scenario, and the maintenance of state for registration
lifetimes in elements outside of the registrar is something we should
not assume by default. 

Thus, I like the notion of having Path be used for incoming requests
normally, but allowing it for outgoing if proxies so desire, in order to
support 3gpp.

3. If this draft moves forward, you will need to have sections for UA,
proxy and registrars defining concise behaviors, such as this issue
above.

-Jonathan R.

Dean Willis wrote:
> 
> I've cobbled together a rough draft of a Path header extension in an
> attempt to meet the a requirement for service route discovery during
> REGISTER for 3GPP established in the Garcia 3GPP requirements draft in
> the SIPPING group.
> 
> <http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt>

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Feb 2002 12:11:09 -0600

Having garbled some formatting on the original and now fixed it (and included a few early comments) I've reissued:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-01.txt

--
Dean