Subject: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Aug 2013 10:16:03 +0000

Hi,

As I indicated at the STOX session (and was later repeated by Jonathan Lennox), the draft need to have a story on SIP forking, e.g. if what happens if the INVITE sent from the interworking node gets forked, and multiple early dialogs are created.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 2 Aug 2013 12:26:10 +0200

Hi Christer,

I would suggest that best practice is for the SIP traffic to be routed to the SIP Proxy/Registrar/Presence Agent of the given domain behind the gateway. That element has more proper capabilities for handling forking or any other SIP features. 

Otherwise you will move all SIP functionality into the XMPP gateway and must document that whole SIP universe as running inside that gateway, which makes little sense.

Regards, 
Adrian

On Aug 2, 2013, at 12:16 PM, Christer Holmberg <[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Aug 2013 10:30:20 +0000

Hi Adrian,

>I would suggest that best practice is for the SIP traffic to be routed to the SIP Proxy/Registrar/Presence Agent of the given domain behind the gateway. That element has more proper capabilities for…

Ok, but how are you going to ensure that such element exists?

Regards,

Christer

Regards,
Adrian

On Aug 2, 2013, at 12:16 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

_______________________________________________
stox mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stox

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 2 Aug 2013 12:35:34 +0200

> Ok, but how are you going to ensure that such element exists?

The gateway knows, it queries the DNS for the domain SIP service records. If no proper records exist, the call flow will stop as there is nothing to rote the calls flows to. 

Such gateway, its very existence, implies that there is both a SIP Server and and XMPP server for each domain. It is a cross protocol federation, the domain must exists otherwise there is nothing to gateway to and there is no reason to deploy it. 

Adrian

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 2 Aug 2013 12:39:21 +0200

Hi,

> As I indicated at the STOX session (and was later repeated by Jonathan Lennox), the draft need to have a story on SIP forking, e.g. if what happens if the INVITE sent from the interworking node get…

I'll propose text but in general terms, since forking doesn't exist in XMPP, the gateway will need to make sure only one reply is relayed to the XMPP side. Also, there dis very little text about early media in XEP-166, I'll look more into that.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Aug 2013 16:55:15 +0000

Hi,

There for sure may be a SIP server (a proxy, B2BUA and/or the remote UAS) in the network, but how can you guarantee that it will handle forking? A forking proxy will simply forward 18x responses forming the early dialogs towards the gateway, which then will have to handle them.

Regards,

Christer

Lähettäjä: Adrian Georgescu [mailto:[email-masked]]
Lähetetty: 2. elokuuta 2013 13:36
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]
Aihe: Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking

On Aug 2, 2013, at 12:30 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

Adrian

Regards,

Christer

Regards,
Adrian

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Aug 2013 16:57:56 +0000

Hi,
 
> I'll propose text but in general terms, since forking doesn't exist in XMPP, the gateway will need to make sure only one reply is relayed to the XMPP side. Also, there dis very little text about ea…

Unfortunately my XMPP knowledge is more or less zero, so at this point I can't really suggest any solution. However, if early media does not exist in XMPP, and the gateway only needs to care about (at least from a media perspective) the 200 OK, there probably is no problem :)

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Sun, 4 Aug 2013 19:20:20 +0200

The gateway lookups the SIP server for a given domain in the DNS same as any other device would do like a SIP phone configured with credentials under that domain. Is the job of that server to properly implement all SIP functions like forking proxy, handle nat traversal or registrar to name a few common features.

You ask what shall the world do if the SIP server of given domain does not implemented forking or other feature. My answer is the gateway must not care, is the problem of whomever manages that domain and its applications to handle such features.

Regards,
Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Aug 2013 18:39:57 +0000

Hi,

I am not sure I understand.

The server may implement SIP functions like forking, and fork the INVITE. BUT, the gateway will still get the 18x responses for the early dialogs - just like a SIP phone.

Regards,

Christer

Lähettäjä: Adrian Georgescu [mailto:[email-masked]]
Lähetetty: 4. elokuuta 2013 20:20
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]
Aihe: Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking

Regards,
Adrian

Hi,

Regards,

Christer

Kopio: [email-masked]<mailto:[email-masked]>

Hi Adrian,

Adrian

Regards,

Christer

Regards,
Adrian

Hi,

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Sun, 04 Aug 2013 20:44:56 +0200

The gateway would care to translate the final response. Getting more 
then one 180 is not causing any harm nor does those need to be 
translated into different events on XMPP side.

Adrian

On 08/04/2013 08:39 PM, Christer Holmberg wrote:
> The server may implement SIP functions like forking, and fork the 
> INVITE. BUT, the gateway will still get the 18x responses for the 
> early dialogs -- just like a SIP phone.
>
> Regards,
>
> Christer
>
> *Lähettäjä:*Adrian Georgescu [mailto:[email-masked]]
> *Lähetetty:* 4. elokuuta 2013 20:20
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* [email-masked]
> *Aihe:* Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
>
> The gateway lookups the SIP server for a given domain in the DNS same 
> as any other device would do like a SIP phone configured with 
> credentials under that domain. Is the job of that server to properly 
> implement all SIP functions like forking proxy, handle nat traversal 
> or registrar to name a few common features.
>
> You ask what shall the world do if the SIP server of given domain does 
> not implemented forking or other feature. My answer is the gateway 
> must not care, is the problem of whomever manages that domain and its 
> applications to handle such features.
>
> Regards,
>
> Adrian
>
> There for sure may be a SIP server (a proxy, B2BUA and/or the remote 
> UAS) in the network, but how can you guarantee that it will handle 
> forking? A forking proxy will simply forward 18x responses forming the 
> early dialogs towards the gateway, which then will have to handle them.
>
> Regards,
>
> Christer
>
> *Lähettäjä:*Adrian Georgescu [mailto:[email-masked]]
> *Lähetetty:*2. elokuuta 2013 13:36
> *Vastaanottaja:*Christer Holmberg
> *Kopio:[email-masked] <mailto:[email-masked]>
> *Aihe:*Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
>
> On Aug 2, 2013, at 12:30 PM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>
> Hi Adrian,
>
> >I would suggest that best practice is for the SIP traffic to be routed 
> to the SIP Proxy/Registrar/Presence Agent of the given domain behind 
> the gateway.That element has more proper capabilities for handling 
> forking or any other SIP features.
>
> The gateway knows, it queries the DNS for the domain SIP service 
> records. If no proper records exist, the call flow will stop as there 
> is nothing to rote the calls flows to.
>
> Such gateway, its very existence, implies that there is both a SIP 
> Server and and XMPP server for each domain. It is a cross protocol 
> federation, the domain must exists otherwise there is nothing to 
> gateway to and there is no reason to deploy it.
>
> Adrian
>
>     Regards,
>
>     Christer
>
>     Otherwise you will move all SIP functionality into the XMPP
>     gateway and must document that whole SIP universe as running
>     inside that gateway, which makes little sense.
>
>     Regards,
>
>     Adrian
>
>     On Aug 2, 2013, at 12:16 PM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>
>
>     Hi,
>
>     As I indicated at the STOX session (and was later repeated by
>     Jonathan Lennox), the draft need to have a story on SIP forking,
>     e.g. if what happens if the INVITE sent from the interworking node
>     gets forked, and multiple early dialogs are created.
>
>     Regards,
>
>     Christer
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 05:12:54 +0000

Hi,

> The gateway would care to translate the final response. Getting more then one 180 is not causing any harm nor does those need to be translated into different events on XMPP side.

If that's the case, then you should have to problem :) I would suggest to have some text about that, though.

And, I assume that means that possible early media from the SIP side won't be forwarded into the XMPP network either, or?

Regards,

Christer

 
 
Regards,
 
Christer

 
 
Regards,
Adrian

Hi,

Regards,
 
Christer

Hi Adrian,

 

Adrian

Regards,
 
Christer

 
Regards, 
Adrian

Hi,

Regards,
 
Christer

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 05 Aug 2013 07:56:11 +0200

> And, I assume that means that possible early media from the SIP side won't be forwarded into the XMPP network either, or?

http://xmpp.org/extensions/xep-0269.html has some suggestions on how to 
do early media. It's not entirely clear to me if the details are correct 
(e.g. I wouldn't use a raw-udp transport when the initiator only 
indicated support for ice-udp) but the general plan seems ok.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 18:10:18 +0200

> translated into different events on XMPP side.

I think Christer's point is that the behavior you are describing needs 
to be described somewhere.

The typical issue is that forking results in multiple early dialogs. 
More than one may result in early media. To give good results the GW 
needs to pass on some or all of that early media to the XMPP side. If 
more than one has early media, then its difficult to know what to do. 
You might pass *one* of them on to the XMPP side.

Most times *one* of those early dialogs will return a 200, and the 
others will be cancelled (by the gateway). But the one that returns the 
200 may not be the one you were processing early media from. So there 
may need to be a media change.

It is also possible that more than one of those early dialogs will 
return a 200. Then *something* needs to be done with all of those. The 
simplest is to hang up on one of them, though its also possible to 
conference them. So the GW needs to deal with this possibility, even 
though it will be rare.

You can *hope* that some sip server downstream of the GW will handle all 
of this and present the GW with a call flow that has no forking. But you 
can't count on this. There is nothing the GW can do to guarantee that 
will happen.

	Thanks,
	Paul

>> early dialogs – just like a SIP phone.
>>
>> Regards,
>>
>> Christer
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 18:17:48 +0200

On 8/4/13 6:57 PM, Christer Holmberg wrote:
> Unfortunately my XMPP knowledge is more or less zero, so at this point I can't really suggest any solution.

Me too.

> However, if early media does not exist in XMPP, and the gateway only needs to care about (at least from a media perspective) the 200 OK, there probably is no problem :)

I'm not sure what it means for early media to not exist in XMPP, or the 
implications of that on an XMPP-SIP GW. If the session is being 
originated from XMPP, and media addresses are provided before the call 
is answered, then early media is possible, even if it will be ignored.

The only way I can see to avoid this entirely is for the GW to initiate 
the initial INVITE without an offer, and *not* support 100rel, so that 
the answer won't be sent until the ACK.

	Thanks,
	Paul

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 8 Aug 2013 00:03:54 +0200

> And, I assume that means that possible early media from the SIP side won't be forwarded into the XMPP network either, or?

My suggestion would be not to do it, since there is no counterpart in XMPP. Yes, there is XEP-269, but it has been deferred.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 8 Aug 2013 00:18:13 +0200

On Aug 6, 2013, at 6:10 PM, Paul Kyzivat wrote:

> I think Christer's point is that the behavior you are describing needs to be described somewhere.
> 

Indeed.

> The typical issue is that forking results in multiple early dialogs. More than one may result in early media. To give good results the GW needs to pass on some or all of that early media to the XMPP side. If more than one has early media, then its difficult to know what to do. You might pass *one* of them on to the XMPP side.
> 

I don't think we can pass the early media, since there is no way to do it today. I'd go for leaving it unspecified. There seems to be some action going on for rebooting Jingle, so when Jingle has a story for early media a new document could be written specifying it. Would this work for you? I know it doesn't cover all those mutli-edarly-dialog cases, but I'm not sure we can do nay better at this point.

> Most times *one* of those early dialogs will return a 200, and the others will be cancelled (by the gateway). But the one that returns the 200 may not be the one you were processing early media from. So there may need to be a media change.
> 

Not if we don't translate early media ;-)

> It is also possible that more than one of those early dialogs will return a 200. Then *something* needs to be done with all of those. The simplest is to hang up on one of them, though its also possible to conference them. So the GW needs to deal with this possibility, even though it will be rare.
> 

Yeah, I think we could add some text about it, though what to do will be implementation specific, right?

> You can *hope* that some sip server downstream of the GW will handle all of this and present the GW with a call flow that has no forking. But you can't count on this. There is nothing the GW can do to guarantee that will happen.
> 

Right.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 8 Aug 2013 00:27:24 +0200

On Aug 5, 2013, at 7:56 AM, Philipp Hancke wrote:

> http://xmpp.org/extensions/xep-0269.html has some suggestions on how to do early media. It's not entirely clear to me if the details are correct (e.g. I wouldn't use a raw-udp transport when the initiator only indicated support for ice-udp) but the general plan seems ok.

Can we rely on it given the fact that is deferred? Are there any plans to change stuff in there, in "Jingle 2.0"?

--
Saúl Ibarra Corretgé
AG Projects

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 08 Aug 2013 20:31:07 +0200

Am 08.08.2013 00:27, schrieb Saúl Ibarra Corretgé:
> Can we rely on it given the fact that is deferred?

Well, it's deferred because of inactivity, i.e. nobody bothered to 
update it or push it to draft.
yate might have an implementation...

> Are there any plans to change stuff in there, in "Jingle 2.0"?

Not that I know of.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Aug 2013 20:27:53 +0200

> I don't think we can pass the early media, since there is no way to do it today. I'd go for leaving it unspecified. There seems to be some action going on for rebooting Jingle, so when Jingle has a…

This is a hard conversation to have, since I am almost totally ignorant 
of Jingle.

But I think what happens here must depend a bit on the nature of the GW. 
If it terminates media, then it can swallow the early media. But if it 
is only a signaling GW, and doesn't terminate the media, then it will 
only be negotiating using the SDP addresses of the SIP and Jingle 
endpoints. In that case its hard to avoid the early media. But it all 
depends on the sort of signaling you can do in the GW.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 10 Aug 2013 14:41:18 +0200

>> I don't think we can pass the early media, since there is no way to do it today. I'd go for leaving it unspecified. There seems to be some action going on for rebooting Jingle, so when Jingle has…
Just answer the call on the jingle side when you have early media. If you haven't got billing on that side, it doesn't matter. If you have billing, then don't answer. Easy to document.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 10 Aug 2013 16:33:59 +0200

On 8/10/13 2:41 PM, Olle E. Johansson wrote:
>
> 9 aug 2013 kl. 20:27 skrev Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>>:
>
>>>> needs to pass on some or all of that early media to the XMPP side.
>>>> If more than one has early media, then its difficult to know what to
>>>> do. You might pass *one* of them on to the XMPP side.
>>>>
>>>
>>> I don't think we can pass the early media, since there is no way to
>>> do it today. I'd go for leaving it unspecified. There seems to be
>>> some action going on for rebooting Jingle, so when Jingle has a story
>>> for early media a new document could be written specifying it. Would
>>> this work for you? I know it doesn't cover all those
>>> mutli-edarly-dialog cases, but I'm not sure we can do nay better at
>>> this point.
>>
> Just answer the call on the jingle side when you have early media. If
> you haven't got billing on that side, it doesn't matter. If you have
> billing, then don't answer. Easy to document.

That doesn't help very often. The case of concern is when the call 
originates from Jingle and an offer is included. This then gets 
gatewayed to SIP, and then forked. At that point each of the forks could 
start sending media back to the media address in the offer.

The Jingle end doesn't have the option to answer the call.

If the GW terminates and relays media, then it is possible for the GW to 
answer the Jingle call, prior to receiving an answer from any fork. Then 
the GW can decide what media to relay.

But that only works if the GW is a media relay. It isn't an option for a 
signaling only GW.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 10 Aug 2013 16:49:54 +0200

10 aug 2013 kl. 16:33 skrev Paul Kyzivat <[email-masked]>:

> That doesn't help very often. The case of concern is when the call originates from Jingle and an offer is included. This then gets gatewayed to SIP, and then forked. At that point each of the forks could start sending media back to the media address in the offer.
> 
> If the GW terminates and relays media, then it is possible for the GW to answer the Jingle call, prior to receiving an answer from any fork. Then the GW can decide what media to relay.
> 
> But that only works if the GW is a media relay. It isn't an option for a signaling only GW.
Right, but I haven't seen anyone really interested in "signaling only" gw's. Emil said multiple times during our IETF meeting that it will be a b2bua anyway.

Early media is just media - it's the billing that's the difference. There's no way to handle multiple early media streams "properly" even if you're a sip b2bua without Jingle at all...

So if you have a jingle endpoint placing a call to a SIP URI and the gateway gets early media from the SIP side, the gateway can answer the jingle call and relay the early media. Whether it wants to mix or stay with the first stream in the case of multiple early media stream is propably up to the implementation - or it's time to specify this behaviour.  Personally I would like to ban sending ring tones with 183 - if they used 180 for ring tones and 183 for other messages a gateway could suspend the ring tones instead of mixing or just ignoring the second media stream.

/O

---

From: Adrian Georgescu <[email-masked]>
Date: Sat, 10 Aug 2013 16:54:09 +0200

> Just answer the call on the jingle side when you have early media. If you haven't got billing on that side, it doesn't matter. If you have billing, then don't answer. Easy to document.

It is already documented.

See draft-ietf-stox-media-billing-cannot-live-without-multiple-leg-cdrs-no-way-without-billing-dtmf-prack-crack-pl-help-01

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 10 Aug 2013 22:22:37 +0000

Hi,
 
>>>>>> More than one may result in early media. To give good results the 
>>>>>> GW needs to pass on some or all of that early media to the XMPP side.
>>>>>> If more than one has early media, then its difficult to know what 
>>>>>> to do. You might pass *one* of them on to the XMPP side.
>>>>>> 
>>>>> 
>>>>> some action going on for rebooting Jingle, so when Jingle has a 
>>>>> story for early media a new document could be written specifying 
>>>>> it. Would this work for you? I know it doesn't cover all those 

A B2BUA does not necessarily control media. Please take a look at http://tools.ietf.org/html/draft-ietf-straw-b2bua-taxonomy-02, which discusses signaling B2BUAs :)

> Early media is just media - it's the billing that's the difference. There's no way to handle multiple early media streams "properly" even if you're a sip b2bua without Jingle at all...

That is correct. The difference is that we are now standardizing the behavior of the GW, so we do need to say something.

> So if you have a jingle endpoint placing a call to a SIP URI and the gateway gets early media from the SIP side, the gateway can answer the jingle call and relay the 
> early media. Whether it wants to mix or stay with the first stream in the case of multiple early media stream is propably up to the implementation - or it's time to 
> specify this behaviour.  Personally I would like to ban sending ring tones with 183 - if they used 180 for ring tones and 183 for other messages a gateway could suspend 
> the ring tones instead of mixing or just ignoring the second media stream.

If you are going to forward all early media from the SIP side (keep in mind that there may be multiple simultaneous early media streams coming from different SIP UASs), you also need to map and forward the SDP information received on each SIP early dialog to the Jingle side.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Sun, 11 Aug 2013 00:33:24 +0200

I am wondering how a SIP session with multiple media types like RTP and MSRP can be translated into an equivalent XMPP signalling without bridging media as well.

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 21:17:31 +0200

> I am wondering how a SIP session with multiple media types like RTP and MSRP can be translated into an equivalent XMPP signalling without bridging media as well.

I suppose the MSRP would indeed have to be terminated by the GW and 
translated into XMPP format. But it could still avoid handling the RTP.

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 14 Aug 2013 21:52:03 +0200

How would that work when there is one SIP session with two media types, RTP audio and MSRP chat, where would such split occur?

Adrian

On Aug 14, 2013, at 9:17 PM, Paul Kyzivat <[email-masked]> wrote:

> I suppose the MSRP would indeed have to be terminated by the GW and translated into XMPP format. But it could still avoid handling the RTP.
> 
> 	Thanks,
> 	Paul
> 
>> Adrian
>> 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 22:19:49 +0200

> How would that work when there is one SIP session with two media types, RTP audio and MSRP chat, where would such split occur?

It depends a bit on how this should look on the xmpp side. (Not my 
thing.) Assuming you can use a single xmpp session for the voice and the 
chat, then it would look something like:

XMPP                                     SIP
CLIENT               GW                  CLIENT
                               sip
                       X=====================
            xmpp       |
   ####################+
                       |       msrp
                       X.....................

                      rtp
   ------------------------------------------

(Sorry if the above is mangled by different clients.) So the GW 
translates sip signaling to/from XMPP signalling. It also terminates the 
MSRP on the sip side, and translates the content into XMPP signaling in 
the same session. But it hands off the RTP addresses from the xmpp 
signaling to sip signaling so that the RTP media passes e2e.

	Thanks,
	Paul

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 16 Aug 2013 10:20:14 +0200

Thanks for confirming, Diana.

On Aug 8, 2013, at 11:53 PM, Diana Cionoiu wrote:

> Hello,
> 
> Yate has an implementation for xep-0269. That was designed talking carefully into consideration the way xmpp work.
> 
> Diana
> 
> On 08/08/2013 11:31 AM, Philipp Hancke wrote:
>> Well, it's deferred because of inactivity, i.e. nobody bothered to update it or push it to draft.

--
Saúl Ibarra Corretgé
AG Projects