Subject: RE: [SIPPING] SDP offer/answer inearly media:draft-sawada-sipping -sip-offeranswer-01.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 Feb 2007 11:35:54 +0000

Christer,

I don't know what you mean by "fake forking", but I think there is an issue
with serial forking, e.g.:
- INVITE request to [email-masked]
- proxy for example.com forwards to PSTN gateway
- PSTN gateway provides early media
- proxy is scripted to cancel the PSTN call after a certain time and forward
the request elsewhere (e.g., to a mobile or voicemail)
- the new destination sends early media or answers quickly and sends regular
media
- the UAC will probably still be rendering early media from the PSTN and
will not know that this is in the process of stopping (even if packets stop
arriving, this could be due to silence)

In this case your proposed 19x provisional response could tell the UAC to
stop listening to the corresponding RTP stream immediately.

John

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 13 February 2007 10:57
> To: Paul Kyzivat; Siddhartha Bhakta
> Cc: [email-masked]; Siddhartha Bhakta; Brian Stucker
> Subject: RE: [SIPPING] SDP offer/answer inearly 
> media:draft-sawada-sipping-sip-offeranswer-01.txt
> 
> 
> Hi,
> 
> I once proposed that it should be possible to terminate an 
> early dialog
> with an 19x provisional response.
> 
> Then, if "fake forking" is used, the dialog not used anymore could be
> terminted and the UAC knows he doesn't have to care about it (and
> possible media coming on it).
> 
> Regards,
> 
> Christer
>  
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]] 
> > Sent: 16. marraskuuta 2006 21:58
> > To: Siddhartha Bhakta
> > Cc: [email-masked]; 'Siddhartha Bhakta'; 'Brian Stucker'
> > Subject: Re: [SIPPING] SDP offer/answer inearly 
> > media:draft-sawada-sipping-sip-offeranswer-01.txt
> > 
> > 
> > 
> > Siddhartha Bhakta wrote:
> > > I agree with you. No matter whether different provisional 
> responses 
> > > are creating different dialogs or not, case is same as 
> far as media 
> > > rendering/committing is concerned. For media committing, 
> there are 
> > > multiple answers for a given offer.
> > > 
> > > Like you, I also can not understand what we are gaining 
> by creating 
> > > multiple dialogs here except the chance to manage 
> > offer/answer state 
> > > as per RFC3261/RFC3264. It seems that multiple SDP answers 
> > for a given 
> > > SDP offer is the reality. We can not avoid that by applying 
> > any tricky 
> > > logic in dialog management (like Fake Forking).
> > 
> > If you ignore dialogs, it becomes impossible to impose any 
> > offer/answer rules.
> > 
> > By paying attention to the separate dialogs, it is possible 
> > to have offer/answer rules that make sense. If you just mix 
> > together offers or answers from multiple destinations it 
> > becomes impossible to make any sense of what you have once it 
> > is determined which dialog will be completed.
> > 
> > For the period when there are multiple dialogs, you have two 
> > different things going on:
> > - an offer/answer state machine is proceeding in each dialog, and
> >    defining the current media parameters for that dialog
> > - you are deciding which dialog(s) you want to process and send
> >    media to.
> > 
> > As Brian notes, it is complex to decide which dialog to honor 
> > during the early stage. But once you settle on one dialog at 
> > least you will then know what to do.
> > 
> > 	Paul
> > 
> > > -----Original Message-----
> > > From: Brian Stucker [mailto:[email-masked]]
> > > Sent: 16 November 2006 17:37
> > > To: Hadriel Kaplan; Siddhartha Bhakta; [email-masked]
> > > Cc: Siddhartha Bhakta
> > > Subject: RE: [SIPPING] SDP offer/answer in early 
> > > media:draft-sawada-sipping-sip-offeranswer-01.txt
> > > 
> > > Fake forking...
> > > 
> > > Please note, if there's SDP in the other provisional 
> > responses, you're 
> > > going to run into problems potentially getting themedia rendered 
> > > (assuming that's your goal).
> > > 
> > > Regards,
> > > Brian
> > > 
> > >> -----Original Message-----
> > >> From: Hadriel Kaplan [mailto:[email-masked]]
> > >> Sent: Sunday, November 12, 2006 8:40 PM
> > >> To: 'Siddhartha Bhakta'; [email-masked]
> > >> Cc: 'Siddhartha Bhakta'
> > >> Subject: RE: [SIPPING] SDP offer/answer in early 
> > >> media:draft-sawada-sipping-sip-offeranswer-01.txt
> > >>
> > >> If the Proxy is sending back SDP by itself it's not a 
> proxy, but a 
> > >> b2bua, as is the PBX.
> > >> As such, it should be answering in a different dialog, 
> so its SDP 
> > >> answer should be in a 183 with a different To-tag from the 
> > 180, and 
> > >> the PBX's 180 SDP should have a different To-tag than 
> the 200ok.  
> > >> That would make them look like a forked call and follow the RFCs.
> > >>
> > >> Of course the reality is often different, but being a 
> > b2bua yourself 
> > >> it's in your power to fix it.  How you do that is not up 
> > to the IETF 
> > >> to define, as the very idea of it goes against the IETF's 
> > view of the 
> > >> world. (and I say that in a positive way, as I think it would be 
> > >> practically impossible for the IETF to do otherwise)
> > >>
> > >> -hadriel
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Siddhartha Bhakta [mailto:[email-masked]]
> > >>> Sent: Sunday, November 12, 2006 2:11 PM
> > >>> To: [email-masked]
> > >>> Cc: [email-masked]; Siddhartha Bhakta
> > >>> Subject: [SIPPING] SDP offer/answer in early
> > >>> media:draft-sawada-sipping- sip-offeranswer-01.txt
> > >>>
> > >>> I am re-sending it as in last email, the figure was distorted.
> > >>>
> > >>> Though, post RFC3261 drafts indicate that one valid 
> > answer would be 
> > >>> there for one SDP offer, the our old friend early-media
> > >> flow is still
> > >>> present in practice.
> > >>>
> > >>> B2BUA/SBC     Proxy         PABX        Bob
> > >>>   |            |            |            |
> > >>>   | INVITE F1  |            |            |
> > >>>   |----------->| INVITE F2  |            |
> > >>>   |   183 F3   |----------->| INVITE F4  |
> > >>>   |<-----------|            |----------->|
> > >>>   |            |            |            |
> > >>>   |            |            |   180 without SDP F5
> > >>>   |            |            |<-----------|
> > >>>   |            |            |            |
> > >>>   |            |  180 with SDP F6        |
> > >>>   |   180 F7   |<-----------|            |
> > >>>   |<-----------|            |  200 F8    |
> > >>>   |            |  200 F9    |<-----------|
> > >>>   |   200 F10  |<-----------|            |
> > >>>   |<-----------|            |            |
> > >>>   |   ACK F11  |            |            |
> > >>>   |----------->|  ACK F12   |            |
> > >>>   |            |----------->|  ACK F13   |
> > >>>   |            |            |----------->|
> > >>>
> > >>> Our B2BUA is facing the problem as specified above.
> > >>> The first answer is carried
> > >>> by F3. This SDP is specified by Proxy. The 2nd SDP answer
> > >> is carried
> > >>> by F6,F7.
> > >>> In fact, this SDP is specified by PABX. The third SDP answer is 
> > >>> carried by F8,F9,F10.
> > >>> This SDP is specified by called party (Bob).
> > >>>
> > >>> As per the RFC3261 & RFC3264, the SDP answer carried by
> > >> F6,F7 should
> > >>> match with F3 as far as B2BUA is concerned. Therefore, 
> > B2BUA shall 
> > >>> ignore it. This is leading to the fact that SIP UA behind 
> > B2BUA can 
> > >>> not listen to ringtone fed by PABX.
> > >>> Similarly, SDP answer carried by F8,F9,F10 shall be 
> ignored. This 
> > >>> shall lead to the fact that SIP UA behind B2BUA can not 
> listen to 
> > >>> Bob's voice. Too bad.
> > >>> This problem is due to the fact that RFC3261 & RFC3264 are not 
> > >>> backward compatible.
> > >>>
> > >>>
> > >>> The sec 2.2. of
> > >>> draft-sawada-sipping-sip-offeranswer-01.txt indicates 
> that UPDATE 
> > >>> should be used to update the media in early media. But in
> > >> practice old
> > >>> early-media flow (i.e., sending different SDPs over 
> different 1xx 
> > >>> responses of
> > >>> INVITE) is quite common.
> > >>> Can we somehow make new SDP offer/answer specified in
> > >>> RFC3261 & RFC3264 backward
> > >>> compatible?
> > >>>
> > >>> The old standard (early-media), allows multiple SDP answers
> > >> of single
> > >>> SDP offer. can we somehow induce this thing in SDP
> > >> offer/answer model? 
> > >>> If many of you think the need of it then I may comeup with
> > >> some thumb
> > >>> rule for the same.
> > >>>
> > >>> Thanks & Regards,
> > >>> Siddhartha
> > >>
> > >> _______________________________________________
> > >> Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > >> This list is for NEW development of the application of SIP Use 
> > >> [email-masked] for questions on 
> current sip Use 
> > >> [email-masked] for new developments of core SIP
> > >>
> > > 
> > > 
> > > 
> > > ---------------
> > > This e-mail may contain confidential and/or privileged 
> > information. If you are not the intended recipient (or have 
> > received this e-mail in error) please notify the sender 
> > immediately and delete this e-mail. Any unauthorized copying, 
> > disclosure or distribution of the contents in this e-mail is 
> > strictly forbidden.
> > > ---------------
> > > 
> > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP 
> > Use [email-masked] for questions on current 
> > sip Use [email-masked] for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Feb 2007 13:11:45 +0100

Hi, 

>I don't know what you mean by "fake forking",

I think your example shows pretty well what I mean :) The only
difference is that I refer to a scenario where the "forking proxy"
actually is a B2BUA that generates early media ITSELF. 

So, it creates a dialog between itself and the UAC. Then it e.g. play
some announcment, and forwards the INVITE to the UAS. The UAS also
creates a dialog between itself and the UAC - which is separate
(different To tag) from the dialog between the UAC and B2BUA. Now, the
UAC sees two dialogs, so it thinks that forking has occured.

>but I think 
>there is an issue with serial forking, e.g.:
>- proxy is scripted to cancel the PSTN call after a certain 
>time and forward the request elsewhere (e.g., to a mobile or 
>voicemail)
>- the new destination sends early media or answers quickly 
>and sends regular media
>- the UAC will probably still be rendering early media from 
>the PSTN and will not know that this is in the process of 
>stopping (even if packets stop arriving, this could be due to silence)
> 
>In this case your proposed 19x provisional response could 
>tell the UAC to stop listening to the corresponding RTP 
>stream immediately.

Yes, that is the idea behind the 19x response.

Regadrs,

Christer

> > I once proposed that it should be possible to terminate an early 
> > dialog with an 19x provisional response.
> > 
> > > By paying attention to the separate dialogs, it is 
> possible to have 
> > > offer/answer rules that make sense. If you just mix 
> together offers 
> > > or answers from multiple destinations it becomes 
> impossible to make 
> > > any sense of what you have once it is determined which 
> dialog will 
> > > be completed.
> > > 
> > > As Brian notes, it is complex to decide which dialog to 
> honor during 
> > > the early stage. But once you settle on one dialog at 
> least you will 
> > > then know what to do.
> > > 
> > > 	Paul
> > > 
> > > information. If you are not the intended recipient (or 
> have received 
> > > this e-mail in error) please notify the sender immediately and 
> > > delete this e-mail. Any unauthorized copying, disclosure or 
> > > distribution of the contents in this e-mail is strictly forbidden.
> > > > ---------------
> > > > 
> > > >

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 13 Feb 2007 07:08:26 -0600

Fake forking is a classic example of the middle screwing up a process
that should only be between final endpoints.

A box in the middle forks the call off to an endpoint that the
originator never intended to call that is acting as if it is one of the
called party's devices, when it is not, and has no intention of ever
answering the call.

Although a 19x response might make knowing when early media from the
interloper to the SDP exchange is no longer necessary, the same thing
can be handled by (most) clients today by simply sending a 180 back to
the originator to switch back to local ringing when that endpoint no
longer has any media it wishes the originator to render (not that the
originator had to render anything in the first place, but that's a
separate discussion).

What would be nice is if each dialog was handled explicitly, rather than
implicitly at the originator for early media (i.e. the originator
explicitly contacts the device that wishes to generate early media
rather than having the network resort to tricking the originator into
rendering the desired media).

I have a draft sitting in the queue that proposes such a mechanism. The
XML2RFC template still used (C) 2006 when I generated the draft text, so
it got bounced during the I-D nits check. Until it appears in the
archives, anyone interested can email me and I'll send you a copy of the
draft.

Regards,
Brian

> Sent: Tuesday, February 13, 2007 9:12 PM
> To: Elwell, John; Paul Kyzivat; Siddhartha Bhakta
> Cc: [email-masked]; Siddhartha Bhakta; Stucker, Brian (RICH1:AR00)
> I think your example shows pretty well what I mean :) The 
> only difference is that I refer to a scenario where the 
> "forking proxy"
> So, it creates a dialog between itself and the UAC. Then it 
> e.g. play some announcment, and forwards the INVITE to the 
> UAS. The UAS also creates a dialog between itself and the UAC 
> - which is separate (different To tag) from the dialog 
> between the UAC and B2BUA. Now, the UAC sees two dialogs, so 
> it thinks that forking has occured.
> 
> >but I think
> >- proxy is scripted to cancel the PSTN call after a certain time and 
> >forward the request elsewhere (e.g., to a mobile or
> >voicemail)
> >- the new destination sends early media or answers quickly and sends 
> >regular media
> >- the UAC will probably still be rendering early media from the PSTN 
> >and will not know that this is in the process of stopping (even if 
> >packets stop arriving, this could be due to silence)
> > 
> tell the UAC 
> >to stop listening to the corresponding RTP stream immediately.
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Feb 2007 14:31:51 +0100

Hi, 

>Fake forking is a classic example of the middle screwing up a 
>process that should only be between final endpoints.

If the B2BUA is providing early media it IS an endpoint.
 
>A box in the middle forks the call off to an endpoint that 
>the originator never intended to call that is acting as if it 
>is one of the called party's devices, when it is not, and has 
>no intention of ever answering the call.

So what? It could as well be an answering machine, or something else
which is never going to answer the call.

Anyway, I think this is more an architecture issue, and has nothing to
do with early media such. From a UAC perspective the call has been
forked, so from that perspective it really doesn't matter if the media
comes from a "real" UAS or from a node in the network.

>Although a 19x response might make knowing when early media 
>from the interloper to the SDP exchange is no longer 
>necessary, the same thing can be handled by (most) clients 
>today by simply sending a 180 back to the originator to 
>switch back to local ringing when that endpoint no longer has 
>any media it wishes the originator to render (not that the 
>originator had to render anything in the first place, but 
>that's a separate discussion).

The simply-sending-back-a-180 is not a standardized mechanism.

And, 19x would help also with other things than early media. For
example, you can release QoS related (or other) resources reserved for
that specific dialog, and you can terminate pre-condition procedures.
19x would not only say "you will not get any media on this dialog" - it
would say "you will not get anything on this dialog, because it doesn't
exist anymore".
 
>What would be nice is if each dialog was handled explicitly, 
>rather than implicitly at the originator for early media 
>(i.e. the originator explicitly contacts the device that 
>wishes to generate early media rather than having the network 
>resort to tricking the originator into rendering the desired media).

I don't understand how that would work. Some of the early media is
generated because I am trying to call YOU.

>I have a draft sitting in the queue that proposes such a 
>mechanism. The XML2RFC template still used (C) 2006 when I 
>generated the draft text, so it got bounced during the I-D 
>nits check. Until it appears in the archives, anyone 
>interested can email me and I'll send you a copy of the draft.

Please do.

Regards,

Christer

> e.g. play 
> > creates a dialog between itself and the UAC
> between the UAC 
> > and B2BUA. Now, the UAC sees two dialogs, so it thinks that forking 
> > has occured.
> > 
> > >but I think
> and sends

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Feb 2007 09:10:23 -0500

> stop listening to the corresponding RTP stream immediately.

I don't see how that would work. To work, the UAC must correlate the 190 
response with the particular media stream being received, so it knows to 
abandon it. But there isn't any well defined way to do that. *If* the 
UAS uses symmetric RTP, and if there is no NAT in the middle, then it 
might be able to do it. I guess this might work in conjunction with ICE.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Feb 2007 15:50:25 +0100

Hi, 

> > I don't know what you mean by "fake forking", but I think 
> there is an 
> time and 
> > forward the request elsewhere (e.g., to a mobile or voicemail)
> the PSTN 
>I don't see how that would work. To work, the UAC must 
>correlate the 190 response with the particular media stream 
>being received, so it knows to abandon it. But there isn't 
>any well defined way to do that. *If* the UAS uses symmetric 
>RTP, and if there is no NAT in the middle, then it might be 
>able to do it. I guess this might work in conjunction with ICE.

True, it MAY not always be possible to correlate the 190 response with
the media stream. On the other hand, if 190 is sent on a dialog, the
media for that dialog will most likely also terminate, since the dialog
with the node sending the media has been terminated.

Regards,

Christer