Subject: Re: [dispatch] Final Charter for Session-ID?

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Thu, 10 Jun 2010 11:51:44 +0200

Hello All,
I agree with Cullen in that the implementer of a B2BUA will need more guidance than is in the proposed charter now in order to decide whether dialogs are related, but I think the first question is how much of this guidance goes in the charter and how much in the working group drafts.

It might help to consider what it means for a UA to provide a correlation header field (e.g. session-ID) at dialog setup. Using the transfer case from Paul below:

>> 	A ----------- B ----------- C
>> 	              |
>> 	              |------------ D

If A adds a session-ID header field, then it means that A is interested in the successful functioning of this session, and B2BUA B has this knowledge when it receives an INVITE from A containing the session-ID header field. At transfer of C to D, the session-ID value shall be the same since A is still in the session. If the transfer is done by D sending an INVITE, then B2BUA B can insert the session-ID. I don't think it matters that D doesn't put the session-ID header field in its INVITE request since correlation is interested in what happens to A, not in the ability of D to enter a session or the ability of C to transfer a session.

Regarding the wording of the charter, I think only one of the two undefined terms "higher-layer session" and "message-flow" should be used (i.e. replace "higher-layer session" with "message-flow" or vice versa).

A possible revision of the charter text is below.

Regards,
Peter

SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter:
----------------------------------
The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate multiple SIP messages and dialogs  across multiple SIP device hops for the purpose of troubleshooting in the case when such messages or dialogs provide
a single communication experience for a single user. A single user may be network entity such as a SIP B2BUA, PBX,
Softswitch, etc. In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as  Application Servers, Softswitches, PBXs, SBCs, etc.

For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under any conditions where correlation might aid troubleshooting,  by identifying them as providing a single communication experience to a single user. A correlation identifier will be duplicated in each dialog that impacts  the communication experience of the user agent that provided that correlation identifier. Any solution documents from this working group may expand or  constrain the scope of their mechanism's correlation, if the working group so decides.

Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header  field, in order to provide a simple, easily deployable mechanism which can work across SIP domains. The SIP Call-ID header field value itself is not usable  for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to comply with the rules of  RFC 3261.

It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853.  The working group will take such functions into  account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's  header field value.

Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this working  group to address that usage.

--------------------------------------------------------------------------
I have a problem with this proposed charter. 

On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote:

> 
> The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice.  For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under any conditions where correlation might aid troubleshooting, by identifying them as belonging to the same higher-level session. Any solution documents from this working group may expand or constrain the scope of their mechanism's correlation, if the working group so decides.

I think the above text is way too vague and impossible to reduce to engineering practice. If you have 10 calls going to a PSTN GWs that is having voice quality problems, clearly having all of them grouped together is useful in debugging. Yet I doubt we want all the calls from a given PSTN GW to have the same correlation ID. Our lack of any solid definition of what it is we are trying to correlate is a strong indication to me that we have not yet come to any consensus about what the problem is this WG would be trying to fix.
 
I would like to see a WG charted in this area but I would expect the IESG to more or less laugh at a problem statement that reduced down to "uh might be useful for debuggin". Can some people please try and propose a more concrete definition of when two sip dialogs will be correlated?

Cullen

Message: 5
Date: Sat, 15 May 2010 00:00:37 -0400
From: Paul Kyzivat <[email-masked]>
Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4
To: Hadriel Kaplan <[email-masked]>
Cc: DISPATCH <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hadriel,

I don't disagree with anything you say below.
But it is also what is troubling to me.

It seems there is no one obvious definition for which dialogs should be related - there are good reasons for each of several possible definitions. Yet its hard to imagine supporting them all. And leaving it to the discretion of each server seems even worse. So I don't see how to decide on a definition.

	Thanks,
	Paul

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email-masked]]
>> Sent: Friday, May 14, 2010 7:56 PM
>>
>> Hadriel Kaplan wrote:
>>> For media-based sessions, such B2BUA's actually can and do represent
>> different media sources at different points in the call; for example 
>> app servers which generate specific tones/music to the UAC while they 
>> hunt for the called party.
>>
>> I find very little difference between this scenario and one where the 
>> call is first answered by a secretary and then transferred to the 
>> intended callee. (Does it matter that the secretary is automated?)
> 
> In the case I was describing, the first dialog leg doesn't reach an established state until the party is found.  If it *did*, which happens in some find-me-follow-me app servers, then I would think they're really separate session-ids.  I'm not super-tide to that position, just seems logical to me for some reason.
> 
>  
>> I'm a bit confused about how things should work if the transfer case 
>> does *not* share the same session-id:
>>
>> 	A ----------- B ----------- C
>> 	              |
>> 	              |------------ D
>>
>> Initially from A via B2BUA B to C, and gets Session-ID X applied to 
>> both the A-B leg and the B-C leg. Then B replaces the B-C "leg" with 
>> the B-D "leg". If the B-D leg doesn't get session-id X, and instead 
>> gets session-ID Y, does A-B then also get a new session-id of Y??? It 
>> seems it must if the correlation is to work for that.
>> That then means that a single dialog, A-B has more than one session-id:
>> X and Y. Is that what is intended???
> 
> In the current Session-ID draft, it makes no statement about that, iirc.  
> I think that's one of the things the SIPSCOTCH WG must decide: whether A-B-D is in fact the same session-id as A-B-C.  If it *is*, then I'd argue a transferred call from A directly to D, replacing A-B-C, is also the same session-id.
> 
> I can see it both ways.  Arguably, if A-B-C got to the established state, that was higher-layer Call-1.  If B-C gets replaced with B-D, then A-B-D is Call-2.  On the other hand, from a troubleshooting perspective it would be nice to know those dialogs are all related.
> 
> Note that once you open the door for the session-id to go beyond the initial established call, it can get weird and complicated.
> 
> For example, what happens if you call a public-announcement broadcaster server; you press some special codes, record an announcement, and press "broadcast"; do the sessions it creates for you use the same session-id as your call?
> 
> Or take your example above, B-D could have replaced B-C by *D* sending 
> an INVITE with replaces to *B*.  So we'd have to get the Session-ID 
> value to D so it can use it in its INVITE to B, like by C passing it 
> in the Refer-To of a REFER to D.  OK, so now imagine if B parked the 
> call and Referred D to C, and you ended up with 2 dialogs A-B, C-D as 
> below.  But they'd be using the same session-id.  Is that legit? 
> (maybe, I dunno)
> 
>  	A ----------- B             C
>  	                            |
>  	                            D
> 
> -hadriel
> 
> 

------------------------------

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

End of dispatch Digest, Vol 14, Issue 37
****************************************

Peter Dawes

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 10 Jun 2010 06:15:27 -0400

Hi,

I also agree that this is a genuine problem. I do think that a few
user cases would cover a large proportion of the common real world
scenarios (auto-attendant, transfer, forward to voice mail etc.) but
that to specify this exhaustively will likely prove difficult.

Is there any support for the idea that the WG should be chartered to
investigate this issue and provide a doc which indicates how B2BUAs
should handle the common cases? Either in the session ID draft or [my
preference] in a second doc (so that e.g. session-id can be used by
sipclf before the the discussion on detailed usage is complete).

Peter Musgrave