Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 14:01:28 -0500

Hi Ian,
Comments inline...

> -----Original Message-----
> From: Ian Elz [mailto:[email-masked]]
> Sent: Monday, December 01, 2008 4:35 AM
>
> I know that we have to work with B2BUAs, and I understand the sentiment
> behind getting rid of them all together. The ietf work tends to preclude
> handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as a
> concatenation of the UAC and UAS then all the ietf specifications have
> to ensure is that each Request can be routed to the correct B2BUA and
> then it is up to the B2BUA to ensure that it performs the correct
> actions for the end-to-end service.

This requires 2 things:
(1) that every B2BUA constantly be upgraded to handle whatever new mechanism's syntax is for the identifiers, every time a new one is defined. (e.g., new XML schema or new header)  I realize that's the nature of "you break it, you fix it", but if people want to have their new thing work without needing B2BUA's to be upgraded or re-configured, then there needs to be some generic way of handling this.
(2) that the mechanism using the call-id+tags gets sent to the B2BUA that changed them.  Often it will.  Sometimes it can't.  For example, the mediactrl-framework model.  Stick a b2bua between the UA and the Media-Control-Client, and the application doesn't work - or wouldn't have, except they changed it to use a new identifier different from call-id to avoid this problem.

> Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be
> globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of
> the B2BUA are different dialogs and must have different Call-ids.

Actually that's debatable.  I don't think we'd want to say B2BUA's MUST change the Call-ID.  3261 did say a B2BUA is the logical concatenation of a UAS and UAC, but clearly not much text in 3261 was given to how a B2BUA should operate.

> The major issue which currently occurs is that a PUI is used to try and
> route a request which should be directed to specific UA, e.g. when
> referencing an extant dialog. To reach the specific UA the Contact
> should be used and if a B2BUA maps the Contact as well as the Call-id
> then the new Request should route to the B2BUA which can perform its
> 'magic' to provide the end-to-end service.

Some folks (from 3gpp) have asked that B2BAU's not change the contact-uri if it's a GRUU, though I'm not exactly sure why.  There are also some cases in which having a B2BUA change the contact to be its specific instance doesn't work, because that address is not globally reachable; so leaving it as a GRUU (or something like a GRUU), is necessary but means out-of-dialog requests don't always reach the same B2BUA instance.  This has been found in REFER transfer cases, where the referred party can't reach the same B2BUA as the referrer can.

-hadriel
_______________________________________________
Sip mailing list  https://www.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: "Scott Lawrence" <[email-masked]>
Date: Mon, 01 Dec 2008 14:33:08 -0500

On Sat, 2008-11-29 at 17:05 -0500, Hadriel Kaplan wrote:
> Sorry Adam somehow I missed your email,
> The idea is to make it something benign enough that operators of
> B2BUA's would not feel the need to mess with it, with as high a
> probability as possible, while still have it be usable and useful.
> One use for it is simply troubleshooting, but I'd like to make it
> usable to help resolve some dialog-matching scenarios that B2BUA's
> currently break.
> 
> The properties it needs to have to be as benign as possible, IMO, are:
> 1) Needs to not identify any identity property of the generator (no
> IP, no host, no domain, no MAC, no username, etc.).  If those are
> incorporated into the identifier, they must not be discernible to a
> receiver of the identifier.
> 2) Needs to not directly reveal the call-id/tags were changed.  This
> is in slight conflict with being usable for dialog-matching, but I put
> text in the latest draft why that's ok and B2BUA's shouldn't care.
> (and I will publish the latest draft ASAP)
> 
> Unfortunately, such a mechanism is not perfect for dialog matching
> uses.  For one, it needs both ends to support it - if middleboxes
> support it they can do it on behalf of the ends, but the farther away
> from the ends they are the less likely the matching will succeed.  It
> also needs B2BUA's to support it - if a B2BUA doesn't, then the
> matching won't work if it hits that B2BUA first.  I think that's all
> ok, because I think that's unavoidable, and it makes things better
> than they are now.
> 
> The other issue with it is a B2BUA can't use the session-id value
> alone for matching, because it wouldn't know which dialog side to
> match to (it has a UAS and possibly multiple UAC dialogs for the same
> session-id).  So the latest draft says matching is done with both the
> session-id and the remote-tag.  That also solves a security issue,
> fwiw.  But it means if any middleboxes along the path muck with the
> remote-tag, they could prevent the matching from succeeding, and we're
> back at square one.  The only solution to that I see would be to have
> surrogates for tags too, but I don't want to go that far down the
> rabbit hole and the draft does not.  If the WG takes this as a WG
> item, then it's all open to consensus of course.

So... given that we already have a call-id that _should_ already have
all the matching properties you want if B2BUAs would just leave it alone
(changing tags as a message passes through a B2BUA should provide the
required dialog uniqueness while leaving the call-id to recognize the
relationships), what is wrong with just creating a new set of rules for
how to construct a call-id so that it has the other properties you
suggest? 

You could even add a magic cookie to the beginning as was done with Via
branch ids to declare that the call-id is a session-id that should be
preserved.  Then it's easy to detect who supports it and understands the
semantics.  

I don't think that reformulating call-id is any harder to deploy than a
new header would be.

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 01 Dec 2008 19:35:37 +0000

On Sat, 2008-11-29 at 17:05 -0500, Hadriel Kaplan wrote:
> If the WG takes this as a WG item, then it's all open to consensus of
> course.

To be clear... I'm very supportive of solving the problems that Hadriel
is pointing out.  For one thing, it would give us a good framework to
begin really classifying and recognizing the various sorts of
middleboxes we have that are not "pure" SIP proxies, and begin
describing what they can and cannot do.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 14:54:56 -0500

> From: Scott Lawrence [mailto:[email-masked]]
> Sent: Monday, December 01, 2008 2:33 PM
>

You missed an email explaining that: if we mandate not changing "safe" call-id values, all b2bua's along the path have to stop changing it, and the UAC has to create a "safe" one.  If we do a new header, only some b2bua's need to change for matching to work in most cases.  All of them would need to pass the header for it to work, but my assumption is that's more likely.  It may be a false assumption, but from the traces I get to see, it looks like new headers get through fairly often. (at least those without URI's)

-hadriel

---

From: "Ian Elz" <[email-masked]>
Date: Tue, 2 Dec 2008 12:21:46 +0100

Hadriel,

Lets get the discussion back to your draft. While we could debate the
merits of B2BUAs for a long time they exist and do some 'interesting'
things.

My main comment on your draft at present is the proposal to allow a
proxy to insert the session-id header if it has not been inserted by the
UA. I think that this introduces additional problems of how to ensure
that the proxy in included in the message path of a new request that
uses the session-id that it inserted as a reference to the original
dialog.

I have included a few comments below.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 01 December 2008 19:01
To: Ian Elz; Dan Wing; James M. Polk
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

Hi Ian,
Comments inline...

> actions for the end-to-end service.

This requires 2 things:
(1) that every B2BUA constantly be upgraded to handle whatever new
mechanism's syntax is for the identifiers, every time a new one is
defined. (e.g., new XML schema or new header)  I realize that's the
nature of "you break it, you fix it", but if people want to have their
new thing work without needing B2BUA's to be upgraded or re-configured,
then there needs to be some generic way of handling this.
(2) that the mechanism using the call-id+tags gets sent to the B2BUA
that changed them.  Often it will.  Sometimes it can't.  For example,
the mediactrl-framework model.  Stick a b2bua between the UA and the
Media-Control-Client, and the application doesn't work - or wouldn't
have, except they changed it to use a new identifier different from
call-id to avoid this problem.

[Ian Elz ] (1) is an issue with B2BUAs. Xavier's b2bua draft was an
attempt to give some guidance on how B2BUAs should behave to make them
as proxy like as possible. (2) I am not familiar with the
mediactrl-framework issues when using the call-id. I will look into this
further.

> the B2BUA are different dialogs and must have different Call-ids.

Actually that's debatable.  I don't think we'd want to say B2BUA's MUST
change the Call-ID.  3261 did say a B2BUA is the logical concatenation
of a UAS and UAC, but clearly not much text in 3261 was given to how a
B2BUA should operate.

[Ian Elz ] It is debatable but section 8.1.1.4 of RFC 3261 does specify:

"   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA."

Thus as the B2BUA is a concatenation of a UAS and a UAC the UAC when it
creates the ongoing out-of-dialog request must create a call-id which is
globally unique which precludes using the call-id which was received by
the UAS part of the B2BUA.

This is pedantic view of the RFC but those are the words which are
included, agreed and published.

> 'magic' to provide the end-to-end service.

Some folks (from 3gpp) have asked that B2BAU's not change the
contact-uri if it's a GRUU, though I'm not exactly sure why.  There are
also some cases in which having a B2BUA change the contact to be its
specific instance doesn't work, because that address is not globally
reachable; so leaving it as a GRUU (or something like a GRUU), is
necessary but means out-of-dialog requests don't always reach the same
B2BUA instance.  This has been found in REFER transfer cases, where the
referred party can't reach the same B2BUA as the referrer can.

[Ian Elz ] I have seen some of the 3gpp CRs which have suggested making
this change. My present view is that this should not be changed. The
solution may be that a B2BUA inserted contact should always be globally
routable or if the received Contact is a gruu then the inserted Contact
should also be a gruu. There is work to be done in this area.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Dec 2008 16:36:25 -0500

Hi Ian, comments inline...

> Sent: Tuesday, December 02, 2008 6:22 AM
>

You mean that a "Proxy" in particular could do this, right? (not that a B2BUA could do this?)

Right now the draft is written to make the matching mechanics basically optional for a node.  The Session-ID header has uses beyond dialog matching ones, and I prefer to keep the bar low for implementations to at least pass it through, or even generate it.  You're right that a Proxy implementing the matching function would need to keep itself in the path - good catch - I will add it if we decide Proxies should be able to do the matching function.  (and yes, it could only keep itself in the path in certain scenarios, so we may just not want to let Proxies do a matching function period to make the draft easier to comprehend)

> as proxy like as possible.

Yes, and my own product does that as well by default (dialog transparency).  Many/most operators turn that off when they install it, fwiw.  But this isn't really about SBC's.  If it were only about SBC's, there would be other ways to skin this cat.  The problem is all B2BUA's.  The number of B2BUA vendors/products/types is scary.  Most of them seem to change Call-ID+tag's all the time, for reasons only they know.  I know it's not due to the security issues.  I know some of them change them to handle spirals correctly.  I know some of them change them for internal architecture reasons.  But I don't know all the reasons.  I can't speak for them.

> routable

That is technically and practically impossible.  If 3GPP thinks it's possible, I suggest they talk to people who actually deploy their technology - i.e., the operators. :)  SBC's have been able to generate the equivalent of GRUU's long before GRUU was invented, and it only works in certain cases.

[and I don't mean that as a slam against 3gpp - it's hard to get the operators' views in the IETF too; and yes I know operators attend 3gpp, but either their voices aren't heard, or they're not aware of the nuances - none of us are aware of the nuances across all sip-related uses, imho]

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Dec 2008 09:56:36 +0000

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 02 December 2008 21:36
> To: Ian Elz
> Cc: SIP List
> Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> 
> Right now the draft is written to make the matching mechanics 
> basically optional for a node.  The Session-ID header has 
> uses beyond dialog matching ones, and I prefer to keep the 
> bar low for implementations to at least pass it through, or 
> even generate it.  You're right that a Proxy implementing the 
> matching function would need to keep itself in the path - 
> good catch - I will add it if we decide Proxies should be 
> able to do the matching function.  (and yes, it could only 
> keep itself in the path in certain scenarios, so we may just 
> not want to let Proxies do a matching function period to make 
> the draft easier to comprehend)
> 
> 
> > This requires 2 things:
> Yes, and my own product does that as well by default (dialog 
> transparency).  Many/most operators turn that off when they 
> install it, fwiw.  But this isn't really about SBC's.  If it 
> were only about SBC's, there would be other ways to skin this 
> cat.  The problem is all B2BUA's.  The number of B2BUA 
> vendors/products/types is scary.  Most of them seem to change 
> Call-ID+tag's all the time, for reasons only they know.  I 
> know it's not due to the security issues.  I know some of 
> them change them to handle spirals correctly.  I know some of 
> them change them for internal architecture reasons.  But I 
> don't know all the reasons.  I can't speak for them.
[JRE] One reason is 3PCC behaviour. Suppose the B2BUA does 3PCC attended
call transfer, i.e., it wants to join together two existing calls, each
with its own call-ID. The resulting call will have different call-IDs on
either side of the B2BUA, even if the original calls had only a single
call-ID each.

John

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 3 Dec 2008 11:47:41 +0100

Hadriel,

Comments in-line. I have removed the bottom part of the discussion.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 02 December 2008 21:36
To: Ian Elz
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

> uses the session-id that it inserted as a reference to the original

You mean that a "Proxy" in particular could do this, right? (not that a
B2BUA could do this?)

[Ian Elz ] I think that a B2BUA could insert the session-id and that
getting back to the B2BUA would have to use the same mechanism as using
the existing call-id/tags dialog referencing for getting the new Request
back to the B2BUA where it could perform the Session-id to call-id/tags
mapping.
For a proxy this is more difficult as ensuring that a proxy appears in
the path of the new request does not appear to have a solution. The
problem with a proxy inserting session-id is that the UA which receives
the request containing the inserted session-id may attempt to create a
new request using the session-id to reference the previous
session/dialog but with no way of definitively routing back via the
proxy which included the session-id the new request is bound to fail. I
think that it is better in this case to not include the session-id and
let the existing mechanisms be used. As session-id usage spreads then
the use of session-id will become more common.

Right now the draft is written to make the matching mechanics basically
optional for a node.  The Session-ID header has uses beyond dialog
matching ones, and I prefer to keep the bar low for implementations to
at least pass it through, or even generate it.  You're right that a
Proxy implementing the matching function would need to keep itself in
the path - good catch - I will add it if we decide Proxies should be
able to do the matching function.  (and yes, it could only keep itself
in the path in certain scenarios, so we may just not want to let Proxies
do a matching function period to make the draft easier to comprehend)

[Ian Elz ] As stated above if the proxy does not support 'matching' then
there is a problem when one UA supports session-id and the other
doesn't. Any attempt to reference a session/dialog using session-id will
fail.

[Ian Elz ] <rest of thread text removed>

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 3 Dec 2008 13:17:24 +0100

Hi, 

>>[Ian Elz ] I have seen some of the 3gpp CRs which have suggested 
>>making this change. My present view is that this should not be 
>>changed. The solution may be that a B2BUA inserted contact should 
>>always be globally routable
> 
>That is technically and practically impossible.  If 3GPP 
>thinks it's possible, I suggest they talk to people who 
>actually deploy their technology - i.e., the operators. :)  
>SBC's have been able to generate the equivalent of GRUU's 
>long before GRUU was invented, and it only works in certain cases.
> 
>[and I don't mean that as a slam against 3gpp - it's hard to 
>get the operators' views in the IETF too; and yes I know 
>operators attend 3gpp, but either their voices aren't heard, 
>or they're not aware of the nuances - none of us are aware of 
>the nuances across all sip-related uses, imho]

Just to clarify: a company brought a CR to the 3gpp meeting, but the CR
was not accepted.

Regards,

Christer

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 02 Dec 2008 21:50:13 -0500

On Wed, 2008-11-19 at 16:46 +0100, Laura Liess wrote:
> B2BUAs being able to generate a new header which contains a string 
> correlated somehow (e.g. a hash) with the call-ID of the initial dialog 
> would be, I think,  a good idea.   There are also two other drafts dealing 
> with dialog correlation: 
> http://www.ietf.org/internet-drafts/draft-worley-references-00.txt which 
> proposes the References-header, containing the Call-ID of the initial dialog 
> and 
> http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt 
> , discussing the requirements for dialog correlation. Both drafts have a 
> quite different focus  but I do not see why we could not use/extend them to 
> cover the B2BUA scenario.  The last draft is on the sipping agenda on 
> Friday.

draft-worley-references-01 contains a section comparing its proposal
with the other two session identification drafts.
(http://tools.ietf.org/html/draft-worley-references-01#section-5)  The
overlap with draft-loreto-sipping-dialog-correlation-01 is rather small,
but draft-kaplan-sip-session-id-00 could be incorporated into the system
of draft-worley-references-01.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 15:23:14 -0500

> Sent: Wednesday, December 03, 2008 5:48 AM
>
>
> the path of the new request does not appear to have a solution.

Actually, there *is* a way of making a Proxy in the path, depending on where the Proxy is.  If it's the edge proxy between the UAC and its registrar, have it insert itself in the Path header for the Register, and any/all requests trying to get to that UA using GRUU/AoR should in theory go through that Proxy.

> doesn't. Any attempt to reference a session/dialog using session-id will

Yes but it would have failed *anyway*.  That's the point - Session-ID is not making it worse.  It's just offering a way to make it better, in certain scenarios.  BTW, for networks like 3GPP the set of scenarios it could cover is rather large, because basically we're talking about the P-CSCF doing this thing, and probably I-BCF's.

And besides, the matching behavior for Session-ID is basically gravy - the meat is getting a common identifier across B2BUA's, for troubleshooting and whatever other needs we find for such an identifier.

If there's consensus that the matching mechanism is too scary/radical to consider, that can be pulled out into a separate draft which uses the Session-ID header value defined in this draft.

-hadriel

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 5 Dec 2008 11:29:43 +0100

Hadriel,

Comments in-line.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

>Sent: 03 December 2008 20:23
>To: Ian Elz
>Cc: SIP List
>Actually, there *is* a way of making a Proxy in the path, depending on
>where the Proxy is.  If it's the edge proxy between the UAC and its
>registrar, have it insert itself in the Path header for the Register,
and
>any/all requests trying to get to that UA using GRUU/AoR should in
theory
>go through that Proxy.

[Ian Elz ] Thus it is only a proxy which is includes itself in the Path
header during registration which is allowed to insert a session-id. Does
a proxy in the Path header remember that it is part of the Path for the
subscriber?
>Yes but it would have failed *anyway*.  That's the point - Session-ID
is
>not making it worse.  It's just offering a way to make it better, in
>certain scenarios.  BTW, for networks like 3GPP the set of scenarios it
>could cover is rather large, because basically we're talking about the
P-
>CSCF doing this thing, and probably I-BCF's.

[Ian Elz ] But having a proxy insert a session-id is not fixing
anything. I am not arguing against the session-id at this point just
allowing proxies to invent one and add then in the middle of a request.
Allowing the proxy to add a session-id requires that the proxy must be
included in the message sequence for the new request using the
session-id as a reference and it must also remember that it inserted the
session-id and map the session-id <--> call-id & tags from one side to
the other when they are used as a reference.
>
>And besides, the matching behavior for Session-ID is basically gravy -
the
>meat is getting a common identifier across B2BUA's, for troubleshooting
and
>whatever other needs we find for such an identifier.

[Ian Elz ] If the session-id is only to be used for troubleshooting then
having a proxy insert the header is not an issue. If it is to be used in
place of the call-id and tags for use in the existing headers (Replaces,
Join, Target-dialog,...) of in Events (dialog etc) then there is an
issue.
I think that we need to define and limit the usage of this header.
>
>If there's consensus that the matching mechanism is too scary/radical
to
>consider, that can be pulled out into a separate draft which uses the
>Session-ID header value defined in this draft.

[Ian Elz ] I am looking at this as a possible solution to the issue of
the mapping of the call-id and tags across B2BUAs and how the headers
and events listed above can be handled across B2BUAs. The current
situation where the B2BUA maps the call-id and or tags requires that the
referencing request is passed along the existing B2BUA chain to allow
the mapping of the previous dialog identifying parameters in the
referencing header. This requires that the B2BUA map the Contact if it
maps any of call-id, from-tag or to-tag and that the new request uses
the Contact from the previous dialog as the R-URI in the referencing
dialog.
In some network implementations there may be service requirements to
pass the referencing request along the B2BUA chain but that is for those
implementations to determine whether the session-id provides a suitable
solution.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 10:51:47 -0500

> Sent: Friday, December 05, 2008 5:30 AM
>
> header during registration which is allowed to insert a session-id.

Nope, that's just one example.  You said there was no way to make a Proxy be in the path for out-of-dialog requests, and I said sure there is.  You could also have a one-and-only Proxy for accepting requests from outside your domain, which could do the matching.  Or the Proxy could be the Registrar for your domain, which is always traversed to reach registered UAs.

Again, though - this is not about who can generate a Session-ID.  It's about who can do the matching.  Every hop can try to do matching for all I care.  It won't affect interoperability or add failure cases where previously there were success cases.  It's only at a MAY level - you don't have to do it if you don't want to.

> the other when they are used as a reference.

Nope, it doesn't require that at all.  See the draft - it's at a MAY to do matching.
I think you may be reading something into the draft that it doesn't say: that only a Session-ID *generator* can do matching?  The draft doesn't say that, nor did I intend it if it does. :)  Should I put words in the draft making that clearer?

-hadriel

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 5 Dec 2008 17:32:44 +0100

Hadriel,

If a proxy inserts a session-id then there will be two sides to the
initial request, the UAC side without the session-id and the UAS side
with a session-id. There may be a number of proxies and/or B2BUAs on
either side of the proxy which inserted the session-id.

When a later request comes from the UAS side which uses the inserted
session-id to reference another dialog which node is going to perform
the matching and modify the referencing header from using the session-id
to using the call-id and tags. The nodes on the UAS side of the
inserting proxy will have received a session-id and will have passed it
on. These nodes have no knowledge that the session-id was inserted in
the middle of the message sequence and hence have no requirement to
perform the matching. The nodes on the UAC side of the original dialog
will not recognize the session-id as it was not in the message and
cannot perform the matching.

The only node which 'knows' that the session-id was inserted was the
node which inserted it. If the session-id was in the original request
from the originating UAC then no matching should occur. To perform
matching in this case would be unproductive as it would introduce the
problem which the header is trying to overcome.

I think that if you are going to allow inserting then you will need a
mechanism that will ensure that the new message will be passed to the
node that can perform the matching, this is the node which inserted it.

If all the things, insertion, matching etc are MAY in the draft I am
beginning to wonder what the purpose of the header is. Perhaps the draft
and consideration of the session-id header should be passed to the
sipping wg to consider the requirements and what problems it is trying
to solve.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 05 December 2008 15:52
To: Ian Elz
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

> header during registration which is allowed to insert a session-id.

Nope, that's just one example.  You said there was no way to make a
Proxy be in the path for out-of-dialog requests, and I said sure there
is.  You could also have a one-and-only Proxy for accepting requests
from outside your domain, which could do the matching.  Or the Proxy
could be the Registrar for your domain, which is always traversed to
reach registered UAs.

Again, though - this is not about who can generate a Session-ID.  It's
about who can do the matching.  Every hop can try to do matching for all
I care.  It won't affect interoperability or add failure cases where
previously there were success cases.  It's only at a MAY level - you
don't have to do it if you don't want to.

> the other when they are used as a reference.

Nope, it doesn't require that at all.  See the draft - it's at a MAY to
do matching.
I think you may be reading something into the draft that it doesn't say:
that only a Session-ID *generator* can do matching?  The draft doesn't
say that, nor did I intend it if it does. :)  Should I put words in the
draft making that clearer?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Dec 2008 12:05:14 -0500

> Sent: Friday, December 05, 2008 11:33 AM
>
> with a session-id.

Yup.

> There may be a number of proxies and/or B2BUAs on

Nope.  The draft is pretty clear that a Proxy or B2BUA would only insert/generate it if and only if it did not already exist.

> perform the matching.

They have no requirement to do so - but that does not prevent them from doing so.

> problem which the header is trying to overcome.

No, the header is not trying to overcome being "unproductive".  I don't dispute that it would be an unnecessary action to perform in some cases.  But again, note that it is not mandatory.  Matching does not introduce interop issues, and does not make it fail when it would have otherwise succeeded.  It's something a node can do if it wishes to.

> node that can perform the matching, this is the node which inserted it.

Can you describe how you think that would be possible for a Session-ID mechanism to do?  Because I don't see a way for that to be possible, given the constraints.

> sipping wg to consider the requirements and what problems it is trying

The requirements are in the draft, as are the problems.  If you don't agree with them that's cool.  If you think they should be expanded or narrowed let me know.  I think you feel that the matching property is not a requirement, or that the solution to it in this doc is not to your liking. (Right?)  But you have not had any complaints with the troubleshooting property, AFAIK.

I see no need to go through bureaucratic procedural hoops which slow down the process of invention, when what they amount to is changing the email mailing list we use but are otherwise the same group of individuals. [no offense to the SIPPING WG, but I think that viewpoint was generally shared by attendees at the last IETF meeting's RAI meeting]

-hadriel

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 08 Dec 2008 18:07:59 +0000

On Mon, 2008-12-01 at 14:54 -0500, Hadriel Kaplan wrote:
> You missed an email explaining that: if we mandate not changing "safe"
> call-id values, all b2bua's along the path have to stop changing it,
> and the UAC has to create a "safe" one.  If we do a new header, only
> some b2bua's need to change for matching to work in most cases.  All
> of them would need to pass the header for it to work, but my
> assumption is that's more likely.  It may be a false assumption, but
> from the traces I get to see, it looks like new headers get through
> fairly often. (at least those without URI's)

I'll take your word for that.

I'm still troubled by what I perceive as an inversion of the names: I
think of a 'session' as something that happens within a 'call'.  I
believe that you're looking for something that's a parent of 'call-id's,
not a child.  Might I suggest 'Call-Set-Id'?

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 13:27:18 -0500

> Sent: Monday, December 08, 2008 1:08 PM
>

Yeah, header names are funny things.  We want them to mean X, but other people interpret them to mean Y, and in reality they end up meaning Z. :)

I used the term "Session-ID" because it was what I thought common operators of SIP deployments would expect it to be, because I think most people think of a Session as actually a superset of a Call-ID - the Call-ID could change 15 times along the path, but it's the same session. (in many ways a Call-ID is not a "Call" identifier at all!)  But I grant that it confuses us with media "sessions".

How about: "Correlation-ID", or even "Opaque-Call-ID"?

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 08 Dec 2008 13:37:19 -0500

On Mon, 2008-12-08 at 13:27 -0500, Hadriel Kaplan wrote:
> Yeah, header names are funny things.  We want them to mean X, but
> other people interpret them to mean Y, and in reality they end up
> meaning Z. :)
> 
> I used the term "Session-ID" because it was what I thought common
> operators of SIP deployments would expect it to be, because I think
> most people think of a Session as actually a superset of a Call-ID -
> the Call-ID could change 15 times along the path, but it's the same
> session. (in many ways a Call-ID is not a "Call" identifier at all!)
> But I grant that it confuses us with media "sessions".
> 

It's treacherous -- the original IETF definition was for "session",
which meant a particular stream of media bytes.  SIP is "Session
Initiation Protocol", a wrapper around sessions.  But with the use of
re-INVITE, one can change the enclosed session in a myriad of ways.

If we're talking about a "sequence" of SIP dialogs which are connected
end-to-end by B2BUAs, then they all enclose the *same* session.  (Which
suggests the common identifier should be put into the SDP!)  But if we
use the identifier to group dialogs in any other way -- and there have
been suggestions to do so -- then we can't call the group of dialogs a
"session" without creating confusion.

Dale

---

From: "Doken, Serhad" <[email-masked]>
Date: Mon, 8 Dec 2008 16:27:29 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale
> Worley
> Sent: Monday, December 08, 2008 10:37 AM
> To: Hadriel Kaplan
> Cc: SIP List; Adam Roach

Such an Sdp attribute will correlate the media streams. It could be problematic if a B2BUA generates a request without Sdp (medialess INVITE etc). 

Looking at it from draft's troubleshooting use case perspective, if one wants to track the signaling flow end-to-end, I like e2e-session-group-id.

Serhad

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 22:44:30 -0500

> From: Doken, Serhad [mailto:[email-masked]]
> Sent: Monday, December 08, 2008 7:27 PM
>
> Such an Sdp attribute will correlate the media streams. It could be
> problematic if a B2BUA generates a request without Sdp (medialess INVITE
> etc).

Not only that, but Session-ID's got nothing to do with media, period.  It's something for any message types, for example a SUBSCRIBE, or MESSAGE, or whatever.  It's more like e2e-call-id.

-hadriel