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

From: <[email-masked]>
Date: Mon, 3 May 2010 17:19:14 +0200

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
> Gesendet: Dienstag, 27. April 2010 20:25
> An: [email-masked]
> Betreff: [dispatch] Using session-id for dialog correlation
> 
> [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?

Hi Hadriel,

thanks for checking it. You are right, that's the idea behind it.

> 
> 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).

The AS has more capabilities than a normal B2BUA, it also looks at the URI in the ressource list, which is UA-B, so it sends the re-INVITE to the call-id 1c side.

> 
> 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.

A dialog initiator, UAs or AS, should not use the same Session-ID for 2 different dialogs. Maybe you remember the discussion we had on the ML with Salvatore on "session-id" for disagregated media, where we came to the conclusion that we should not use the same id.

> 
> 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.

It's true, this is a potential source of problems. We took this into account for the 3GPP use cases (e.g. the communications are in the HOLD state from the perspective of the left B2BUA).

> 
> 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?

If the AS checks the body with the resource list this would be the ideal solution. But most B2BUAs today do not understand RL.. So we had to look for an e2e dialog correlator.
Unfortunately indeed every call has to be an AS call. But this is also the case for a number of other IMS services, caused by the IMS architecture where the AS hosts a number of services, so it won't be only the 3PTY conference which causes the AS call. It's more like that it's routed via the AS anyway, so let's use it to send the re-INVITEs (see below).

> 
> 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. 

The problem is it is not predictable if the invited UAs really accept the INVITE from the conference focus, even if there is a Replaces header. Many of them simply answer with 486, because they are already in a dialog with the conference initiator. This is even more the case if the UA is in the PSTN, a usecase we always have to consider at 3gpp. When you send a re-INVITE in the existing dialog it's very likely the invited UA accepts. And you are able to restore the original communications from before the conference rather quickly, which is also quite important for a 3PTY conference.

Regards, Martin

> 
> 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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 May 2010 12:11:20 -0400

> Unfortunately indeed every call has to be an AS call. But this is also the case for a number of other IMS services, caused by the IMS architecture where the AS hosts a number of services, so it won…

Even in the simplest case, where a new INVITE is not forked, and goes to 
a single UAS that responds with 200? I understand why the AS would be 
included in the initial routing of the call, but I would think in such a 
case it would not R-R, and so would be out of the call once the dialog 
was established.

Of course it would then not be present for mid-call actions, like transfers.

But its a very specialized architecture that has such a thing in *every* 
call. IMS *is* such a specialized architecture. But then we perhaps 
don't want to be devising a session-id mechanism that is only useful in 
that environment.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 May 2010 15:52:12 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, May 03, 2010 11:19 AM
> To: Hadriel Kaplan; [email-masked]
> Subject: AW: [dispatch] Using session-id for dialog correlation
> 
> > From Hadriel:
> The AS has more capabilities than a normal B2BUA, it also looks at the URI
> in the ressource list, which is UA-B, so it sends the re-INVITE to the
> call-id 1c side.

I think that's brittle - by "brittle" I mean makes assumptions about the network that will not be true in all cases and cause it to fail. (maybe)

For example, assume the following call-flow:

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

Note that now there are *two* AS's in the path.  This is like the original drawing, but the call got routed by the first AS to a stateful-Proxy or B2BUA, which sent it to a second AS.

Now imagine that the AS on the left and the one on the right are the *same* AS.  (That's not as unlikely as one would think, especially in 3gpp)

So the AS gets a RL with wrong info, but a matching session-id and a RL-entry for UA-B.  Would it bypass the B2BUA in the middle for the re-INVITE, because it finds UA-B in its local table?

> A dialog initiator, UAs or AS, should not use the same Session-ID for 2
> different dialogs. Maybe you remember the discussion we had on the ML with
> Salvatore on "session-id" for disagregated media, where we came to the
> conclusion that we should not use the same id.

I don't remember it, but I'm not sure it matters: take the example above.  The call comes into the AS, goes to a next-hop B2BUA without forking, gets routed back to the same AS, and voilà: 2 dialogs on the AS with the same session-id.

> If the AS checks the body with the resource list this would be the ideal
> solution. But most B2BUAs today do not understand RL.. So we had to look
> for an e2e dialog correlator.

But you can make them do so.  They are under the same administrative control, and subject to 3GPP specs, no?

-hadriel

---

From: <[email-masked]>
Date: Thu, 6 May 2010 18:57:45 +0200

> Von: Hadriel Kaplan [mailto:[email-masked]] 
> Gesendet: Montag, 3. Mai 2010 21:52
> An: Hülsemann, Martin; [email-masked]
> Betreff: RE: [dispatch] Using session-id for dialog correlation
> 
> 
> 
> > > 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).
> > 
> > The AS has more capabilities than a normal B2BUA, it also 
> looks at the 
> > URI in the ressource list, which is UA-B, so it sends the 
> re-INVITE to 
> > the call-id 1c side.
> 
> I think that's brittle - by "brittle" I mean makes 
> assumptions about the network that will not be true in all 
> cases and cause it to fail. (maybe)
> 
> Note that now there are *two* AS's in the path.  This is like 
> the original drawing, but the call got routed by the first AS 
> to a stateful-Proxy or B2BUA, which sent it to a second AS.
> 
> Now imagine that the AS on the left and the one on the right 
> are the *same* AS.  (That's not as unlikely as one would 
> think, especially in 3gpp)
That's too true.

> 
> So the AS gets a RL with wrong info, but a matching 
> session-id and a RL-entry for UA-B.  Would it bypass the 
> B2BUA in the middle for the re-INVITE, because it finds UA-B 
> in its local table?
So the problem is that the AS now has the choice wether to send the re-INVITE in dialog 1b or dialog 1d, do I understand correct? 
If the AS gets involved several times during session initiation with the same Session ID, it would have to store the related Dialog IDs in order, and then send the re-INVITE in the first dialog it has linked with the Session ID (and of course linked with UA-B). 
A mechanism like this could be part of the solution. But of course this is not a trivial problem, and we have to consider it very carefully at the further development of this IMS service.

> 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.
> > 
> > A dialog initiator, UAs or AS, should not use the same 
> Session-ID for 
> > 2 different dialogs. Maybe you remember the discussion we 
> had on the 
> > ML with Salvatore on "session-id" for disagregated media, where we 
> > came to the conclusion that we should not use the same id.
> 
> I don't remember it, but I'm not sure it matters: take the 
> example above.  The call comes into the AS, goes to a 
> next-hop B2BUA without forking, gets routed back to the same 
> AS, and voilà: 2 dialogs on the AS with the same session-id.
The same as above, the AS would have to order the dialogs somehow.

> 
> 
> > > 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?
> > 
> > If the AS checks the body with the resource list this would be the 
> > ideal solution. But most B2BUAs today do not understand 
> RL.. So we had 
> > to look for an e2e dialog correlator.
> 
> But you can make them do so.  They are under the same 
> administrative control, and subject to 3GPP specs, no?
Actually the behaviour of and the requirements for B2BUAs are not described very well yet. And the other problem is, they do allready exist in the network. While we could define requirements for new ones (and hope vendors will implement), it's very difficult to change the functionality of existing ones. And this could lead to the situation one old B2BUA could destroy the whole service.

Regards, Martin