Subject: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Aug 2007 15:10:25 +0200

Dear SIP WG members,

during the ECRIT meeting we learned that the SIP working group 
"rejected" the concept described in 
draft-rosenberg-sip-ua-loose-route-01.txt.

Could someone please give us more information about this decision as it 
impacts the work we do in ECRIT?

Ciao
Hannes

_______________________________________________
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: Hannes Tschofenig <[email-masked]>
Date: Sun, 26 Aug 2007 20:41:06 +0200

No response received -- resend.

Hannes Tschofenig wrote:
> Could someone please give us more information about this decision as 
> it impacts the work we do in ECRIT?
>
> Ciao
> Hannes
>
>
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Aug 2007 00:45:29 -0500

>> it impacts the work we do in ECRIT?

I wouldn't say that UA Loose Route was "rejected" so much as "does not 
yet have consensus".

This is in part influenced by "WG doesn't seem to have a compelling 
reason to make such a significant change."

Perhaps ECRIT has a compelling reason?

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Aug 2007 12:54:27 -0500

Frankly, I tought the conclusion was to investigate if pros and cons of
two approches:

1 - Loose route approach
2 - Having a header with the original target (P-Called-Party-ID, RFC
3455)

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Sunday, August 26, 2007 22:45
> To: Hannes Tschofenig
> Cc: IETF SIP List; ECRIT
> Subject: Re: [Ecrit] Re: [Sip] 
> draft-rosenberg-sip-ua-loose-route-01.txt
> 
> Hannes Tschofenig wrote:
> I wouldn't say that UA Loose Route was "rejected" so much as 
> "does not yet have consensus".
> 
> This is in part influenced by "WG doesn't seem to have a 
> compelling reason to make such a significant change."
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Peili Xu <[email-masked]>
Date: Tue, 28 Aug 2007 10:46:31 +0800

Yes, although there are comments and objections, 
I didn't aware of such consensus that the draft was
totally objected by the WG.

Actually, part of the solution is interesting to me.

Assuming we could group the problem statements into 3
categories: 
a) conversion for contact binding; b) conversion for
routing resolution and c) conversion for services.

1: I'd suggest using P-Called-Party-ID to for category
a) problem and loose routing for the other 2.

    and I think Ecrit problem can be categoried as
problem b or c.

2: When would proxy apply loose route after conversion
for category b/c is subject to local policy or some kind
of indication provided by external conversion/mapping
service. 

3: How to define a uri parameter for sub-address purpose
is somewhat independent from the draft to me.
But it's interesting. I'd suggest specifying it
separately and with thorough considerations for how to
implement sub-address like services in SIP.

Cheers.
Peili

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 1:54 AM
To: Dean Willis; Hannes Tschofenig
Cc: IETF SIP List; ECRIT
Subject: RE: [Ecrit] Re: [Sip]

Frankly, I tought the conclusion was to investigate if
pros and cons of two approches:

1 - Loose route approach
2 - Having a header with the original target
(P-Called-Party-ID, RFC
3455)

> >> Could someone please give us more information about
this
> decision as
> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
> [email-masked] for questions on
current sip Use 
> [email-masked] 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 [email-masked] for
questions on current sip Use [email-masked] for new
developments on the application of sip