Subject: [dispatch] Using session-id for dialog correlation

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 14:24:49 -0400

[sorry for the long email, but it's a complicated topic]

A few people have mentioned that the session-id draft should not only be for troubleshooting, but for dialog correlation as well.  

Specifically to handle this type of scenario, based on 3GPP 24.605 annex A.2.2

  +----+      +-----+      +----+      +-----+      +----+
  |UA-A|      |B2BUA|      | AS |      |B2BUA|      |UA-B|
  +----+      +-----+      +----+      +-----+      +----+
    |            |            |           |            |
    |INVITE      |            |           |            |
    |callid:1a   |callid:1b   |callid:1c  |callid:1d   |
    |----------->|----------->|---------->|----------->|
    |sessid:1    |sessid:1    |sessid:1   |sessid:1    |
    |            |            |           |            |
    |INVITE      |            |           |            |
    |callid:2a   |callid:2b   |           |            |
    |----------->|----------->|           |            |
    |sessid:2    |sessid:2    |re-INVITE  |            |
    |RL<sessid:1>|RL<sessid:1>|callid:1c  |callid:1d   |
    |            |            |---------->|----------->|
    |            |            |sessid:1   |sessid:1    |
    |            |            |           |            |

[note: this is a simplified drawing from 3gpp's - in 3gpp it has two called parties: UA-B and UA-C, but it doesn't really matter with regards to the problem]

Explanation of drawing:
UA-A has a call with UA-B through multiple B2BUA's and an Application Server.  The dialogs of that call all have the same session-id, but unique call-id/tags.

UA-A wants to invoke a 3rd party conference facility in the AS, and reference the call with UA-B for that.  In this particular 3gpp scenario, to do that UA-A sends a new INVITE to the AS with a resource-list body (a la RFC 5366) containing the call information for the original call.  This is the "RL<sessid:1>" piece in the diagram.  It has the calli-d/tags as well, but they'll be wrong when received at the AS.

The AS processes that list, can't match the callid/tags in the resource-lit but does match the session-id, and sends a re-INVITE to party B within the original call's dialog.

Do I have that right?

I think there are problems doing that. :(

1) The Session-ID only provides a single value which is the same on both "sides" of a B2BUA.  The AS *is* a B2BUA, so when it gets the resource-list with a Session-ID, how does it know which side of session-id 1 to re-INVITE?  I.e., how does it know to send a re-INVITE to call-id 1c vs. 1b?  The tags were there to do that, but they no longer match.  We could define a flag/param for Session-ID to indicate uac vs. uas, if you think that would help (I was prepared to do that in the draft at one point, to avoid this problem).

2) What if the AS has multiple dialogs for that same Session-ID?  It could have - for example in a "normal" ad-hoc rfc5366 conference scenario the AS could have invited multiple participants to the same initial conference call, and could arguably use the same session-id for all legs.  So if another invite referred to that conference call, it would be ambiguous which leg it meant.

3) Let's say this call-flow actually worked, and the AS sent the re-INVITE to UA-B.  At that point, the B2BUA(s) on the left-hand side of the AS are no longer in synch with regards to the call or media state.  For example, some B2BUA's will tear-down the call if media stops flowing through them for too long.  In this specific 3gpp spec it says the call was put on hold before-hand, so that won't happen, but you get the idea: "bypassing" b2bua's is brittle.

4) In this *particular* scenario the solution is easier: make the B2BUA's understand resource-lists, and make them change the callid/tags in them correctly.  After all, that's what's causing the mismatch at the AS.  But isn't this a rather unlikely/rare scenario?  I mean do you really intend every call to go through an AS, just in case it ends up becoming a 3pcc conf call?

But I also don't understand why 3gpp has this call flow this way.  I'm not an expert on conference call models by any stretch, and I'm not trying to second-guess 3gpp, but it seems to me that this isn't what should happen in this call case.  From a logical perspective, the AS getting the resource-list should try to match the URI's in it.  When it doesn't find them, it should act *exactly* as it would if it were not by coincidence the same AS which was in the original call flows - in other words, it should generate new INVITEs with a Replaces header for the callid/tags in the resource-list.  Those would go to the URI's in the resource-list, which would be the B2BUA that UA-A made the original call to.  The AS will eventually get that INVITE with Replaces back again, through that b2bua, things match up, and all is good.  

It's more signaling, but really this call scenario is rare to begin with and you need the call signaling to avoid the issues raised earlier.  And it will actually replace the original call dialogs, which is a good thing.  And it will work the same way as cases where the conference AS is not by coincidence the same as the original calls. (I think)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 14:48:49 -0400

Just to be clear, I use the term "B2BUA" in the sense of not being a generic 3261 proxy.  I am not referring to SBC's.  In the 3gpp diagram these were labeled as "Intermediate IM CN subsystem entities", which could be 3261 proxies; but the diagram shows them changing the call-id and thus I just labeled them as "B2BUA" to be simpler.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Tuesday, April 27, 2010 2:25 PM
> To: [email-masked]
> Subject: [dispatch] Using session-id for dialog correlation
> 
> A few people have mentioned that the session-id draft should not only be
> for troubleshooting, but for dialog correlation as well.
> 
> [note: this is a simplified drawing from 3gpp's - in 3gpp it has two
> called parties: UA-B and UA-C, but it doesn't really matter with regards
> to the problem]
> 
> Explanation of drawing:
> UA-A has a call with UA-B through multiple B2BUA's and an Application
> Server.  The dialogs of that call all have the same session-id, but unique
> call-id/tags.
> 
> UA-A wants to invoke a 3rd party conference facility in the AS, and
> reference the call with UA-B for that.  In this particular 3gpp scenario,
> to do that UA-A sends a new INVITE to the AS with a resource-list body (a
> la RFC 5366) containing the call information for the original call.  This
> is the "RL<sessid:1>" piece in the diagram.  It has the calli-d/tags as
> well, but they'll be wrong when received at the AS.
> 
> The AS processes that list, can't match the callid/tags in the resource-
> lit but does match the session-id, and sends a re-INVITE to party B within
> the original call's dialog.
> 
> Do I have that right?
> 
> 1) The Session-ID only provides a single value which is the same on both
> "sides" of a B2BUA.  The AS *is* a B2BUA, so when it gets the resource-
> list with a Session-ID, how does it know which side of session-id 1 to re-
> INVITE?  I.e., how does it know to send a re-INVITE to call-id 1c vs. 1b?
> The tags were there to do that, but they no longer match.  We could define
> a flag/param for Session-ID to indicate uac vs. uas, if you think that
> would help (I was prepared to do that in the draft at one point, to avoid
> this problem).
> 
> 2) What if the AS has multiple dialogs for that same Session-ID?  It could
> have - for example in a "normal" ad-hoc rfc5366 conference scenario the AS
> could have invited multiple participants to the same initial conference
> call, and could arguably use the same session-id for all legs.  So if
> another invite referred to that conference call, it would be ambiguous
> which leg it meant.
> 
> 3) Let's say this call-flow actually worked, and the AS sent the re-INVITE
> to UA-B.  At that point, the B2BUA(s) on the left-hand side of the AS are
> no longer in synch with regards to the call or media state.  For example,
> some B2BUA's will tear-down the call if media stops flowing through them
> for too long.  In this specific 3gpp spec it says the call was put on hold
> before-hand, so that won't happen, but you get the idea: "bypassing"
> b2bua's is brittle.
> 
> 4) In this *particular* scenario the solution is easier: make the B2BUA's
> understand resource-lists, and make them change the callid/tags in them
> correctly.  After all, that's what's causing the mismatch at the AS.  But
> isn't this a rather unlikely/rare scenario?  I mean do you really intend
> every call to go through an AS, just in case it ends up becoming a 3pcc
> conf call?
> 
> But I also don't understand why 3gpp has this call flow this way.  I'm not
> an expert on conference call models by any stretch, and I'm not trying to
> second-guess 3gpp, but it seems to me that this isn't what should happen
> in this call case.  From a logical perspective, the AS getting the
> resource-list should try to match the URI's in it.  When it doesn't find
> them, it should act *exactly* as it would if it were not by coincidence
> the same AS which was in the original call flows - in other words, it
> should generate new INVITEs with a Replaces header for the callid/tags in
> the resource-list.  Those would go to the URI's in the resource-list,
> which would be the B2BUA that UA-A made the original call to.  The AS will
> eventually get that INVITE with Replaces back again, through that b2bua,
> things match up, and all is good.
> 
> It's more signaling, but really this call scenario is rare to begin with
> and you need the call signaling to avoid the issues raised earlier.  And
> it will actually replace the original call dialogs, which is a good thing.
> And it will work the same way as cases where the conference AS is not by
> coincidence the same as the original calls. (I think)
> 
> -hadriel
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch