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

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

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

---

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

Hi,

Regards,

Christer

> If you ignore> >>>   |            |----------->|  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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Feb 2007 08:44:48 -0500

> with an 19x provisional response.

How do you see this being used with "real" forking? Would the proxy that 
is doing the forking send the 190 response on behalf of early dialogs 
that it is canceling?

> possible media coming on it).

What is the prevalence of "fake" forking relative to "real" forking with 
early media?

I think there are merits to this approach, though it needs to be worked 
out in detail.

	Paul

>>>>>   |            |----------->|  ACK F13   |
>>>>>   |            |            |----------->|
>>>>>

---

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

Hi, 

>>I once proposed that it should be possible to terminate an early 
>>dialog with an 19x provisional response.
> 
>How do you see this being used with "real" forking? Would the 
>proxy that is doing the forking send the 190 response on 
>behalf of early dialogs that it is canceling?

Yes. 

Also, if the forking proxy receives a 456xx from a UAS it can forward a
190 towards the UAC (forwarding the 456xxx would terminate the whole
call setup).

>What is the prevalence of "fake" forking relative to "real" forking
with early media?

I don't, but at least in TISPAN "fake forking" is a specified mechanism
for announcement sending by an AS.

Regards,

Christer

out in detail.

> >> 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: [email-masked]
Date: Wed, 14 Feb 2007 17:41:20 -0500

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>

That seems like it might be useful, given the number of times I've
seen "fake forking" proposed for dealing with one situation or
another.

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 15 Feb 2007 12:33:15 +0100

Hi,

It seems like a number of people now seem to be interested in at least
investigating the possible usage of 19x, so I will try to put together a
draft which we can use as base for the discussion.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 15. helmikuuta 2007 0:41
> To: [email-masked]
> Subject: Re: [SIPPING] SDP offer/answerinearly 
> That seems like it might be useful, given the number of times 
> I've seen "fake forking" proposed for dealing with one 
> situation or another.
> 
> Dale
>