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 14:57:24 +0000

Paul,

Yes, I failed to elaborate on that. Another means of correlation is if MIKEY
is used or if something along the lines of the Stucker early-media-coping
draft. These two mechanisms would provide the SSRC value, but unfortunately
that is still not guaranteed to be unique.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 13 February 2007 14:10
> To: Elwell, John
> Cc: Christer Holmberg (JO/LMF); Siddhartha Bhakta; 
> [email-masked]; Siddhartha Bhakta; Brian Stucker
> Subject: Re: [SIPPING] SDP offer/answer inearly 
> media:draft-sawada-sipping -sip-offeranswer-01.txt
> 
> 
> 
> Elwell, John wrote:
> > 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.
> 
> 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
> 
> > 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