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 13:33:58 +0000

Brian,

See below,

John 

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: 13 February 2007 13:08
> To: Christer Holmberg (JO/LMF); Elwell, John; Paul Kyzivat; 
> Siddhartha Bhakta
> Cc: [email-masked]; Siddhartha Bhakta
> Subject: RE: [SIPPING] SDP offer/answer inearly 
> media:draft-sawada-sipping-sip-offeranswer-01.txt
> 
> 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).
[JRE] I don't think 180 means that. It means play ringback tone until media
starts to arrive. If media is already arriving, I don't think 180 has the
semantics of stop rendering media and revert to ringback tone. I don't even
think it has the semantics of wait until media appears to have stopped and
then revert to ringback tone. I am not saying that one of these would not be
an unreasonable thing to do, and also I am not denying that some
implementations might do one of these already. But I don't know where it is
specified in an RFC. Perhaps some clarification is needed.

> 
> 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.
[JRE] Yes please

> 
> Regards,
> Brian
> 
> > -----Original Message-----
> > From: Christer Holmberg (JO/LMF) 
> > [mailto:[email-masked]] 
> > Sent: Tuesday, February 13, 2007 9:12 PM
> > To: Elwell, John; Paul Kyzivat; Siddhartha Bhakta
> > Cc: [email-masked]; Siddhartha Bhakta; Stucker, Brian (RICH1:AR00)
> > Subject: RE: [SIPPING] SDP offer/answer inearly 
> > media:draft-sawada-sipping-sip-offeranswer-01.txt
> > 
> > 
> > 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.:
> > >- 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.
> > 
> > Yes, that is the idea behind the 19x response.
> > 
> > Regadrs,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > > > -----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: [email-masked]
Date: Wed, 14 Feb 2007 17:40:25 -0500

From: "Elwell, John" <[email-masked]>

   starts to arrive.

It doesn't mean that, either.  It means that the UAS that was reached
is declaring that it is notifying a user.  Whether or how the UAC
wishes to notify its user of this fact is its business.

Currently, SIP has no defined means for indicating "Stop playing the
ringback and start playing this media stream."

Dale

---

From: "Ejzak, Richard P \(Richard\)" <[email-masked]>
Date: Wed, 14 Feb 2007 17:22:07 -0600

> From: [email-masked] [mailto:[email-masked]] 
> 
> It doesn't mean that, either.  It means that the UAS that was 
> reached is declaring that it is notifying a user.  Whether or 
> how the UAC wishes to notify its user of this fact is its business.
> 
> Currently, SIP has no defined means for indicating "Stop 
> playing the ringback and start playing this media stream."

Actually, that is one of the features of the P-Early-Media header in
draft-ejzak-sipping-p-em-auth-03.txt, which Gonzalo tells me has been
requested for publication.  By explicitly authorizing or not authorizing
early media, and changing that authorization if necessary, the UAC can
know when it should play ringback or the media stream.  Strictly
speaking, however, RFC 3960 does recommend the UAC policy that John
describes.  It's just not normative.

Regards,
Richard

---

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

Hi, 

>[JRE] I don't think 180 means that. It means play ringback 
>tone until media starts to arrive.
> 

In TISPAN the usage of P-Early-Media header solves that, at least to
some extent.

Regards,

Christer

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 16 Feb 2007 05:20:30 -0600

Well... Sorta. It just says it's no longer authorized. You have to get
the timing straight to switch between two streams.

Regards,
Brian 

> Sent: Thursday, February 15, 2007 8:31 PM
> To: [email-masked]; [email-masked]
> In TISPAN the usage of P-Early-Media header solves that, at 
> least to some extent.
> 
> Regards,
> 
> Christer
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>