Hi,

I guess we should also look at the text in 3261 regarding this as part
of the fix-the-bugs-in-3261 work that was initiated in Prague.

Regards,

Christer


> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Christer Holmberg (JO/LMF)
> Sent: 12. huhtikuuta 2007 9:58
> To: Paul Kyzivat
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] VS: SDP offer/answer for delay media
> 
> 
> Hi Paul,
> 
> I am definately not saying that people should put their SDPs 
> wherever they want.
> 
> I am saying that people should look at this issue from a o/a 
> state machine perspective, and not only focus on whether 
> there is an SDP body in a message or not.
> 
> For example, you say that if the offer was sent in a reliable 
> 18x, you find no rationale to include a copy of it again in 
> 200. I am not sure I think it's that clear, but that we could 
> argue about forever. The important thing is that IF a SDP has 
> already been sent reliable in 18x, it should not matter 
> what/if you include in 200.
> 
> Regards,
> 
> Christer
>  
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> > Sent: 11. huhtikuuta 2007 22:57
> > To: Christer Holmberg (JO/LMF)
> > Cc: Bu, Wenfei (Leo); [EMAIL PROTECTED]
> > Subject: Re: VS: [Sip-implementors] SDP offer/answer for delay media
> > 
> > Christer,
> > 
> > Your comments indicate how including SDP in extra places would not 
> > constitute offers or answers and so how it ought not cause problems.
> > 
> > But regardless of that, SDP in those places does not seem to be 
> > allowed by existing standards. There is already enough problem with 
> > redundant SDP that was grandfathered in by the wording of 
> the specs, 
> > and it has proven to cause trouble. So I would not want to 
> explicitly 
> > allow this in other places.
> > 
> > If you want to put SDP in these places, in a non-conformant 
> way, with 
> > the expectation that others will not be bothered by it, 
> they you are 
> > free to try that. But don't complain if somebody handles it 
> in a way 
> > different from what you expect.
> > 
> >     Paul
> > 
> > Christer Holmberg (JO/LMF) wrote:
> > > Hi,
> > > 
> > >>> All,
> > >>>
> > >>> This was talked before but it still looks not clear:
> > >>>
> > >>> UAC                   UAS
> > >>>
> > >>> ----------->F1 INVITE w/o SDP
> > >>>
> > >>> <-----------F2 18X w/ SDP1
> > >>>
> > >>> ----------->F3 PRACK w/ SDP2
> > >>>
> > >>> <-----------F4 200 for PRACK
> > >>>
> > >>> <-----------F5 200 for INVITE w/ SDP1
> > >>>
> > >>> ----------->F6 ACK (w/ SDP2 ???)
> > >>>
> > >>>
> > >>>
> > >>> My questions:
> > >>>
> > >>> 1. Could 200 for INVITE in F5 carry an SDP?
> > > 
> > >> No. There has already been one o/a in the transaction 
> initiated F1.
> > >> There cannot be another offer in the same transaction.
> > > As far as I understand, the 200 for INVITE does not carry a
> > new offer. It carries the same answer that was carried in 18x (F2).
> > > 
> > > 
> > >> In the case where the invite carries an offer sdp, and
> > there is SDP
> > >> in a provisional response that same sdp can be in the 200. That 
> > >> wording in
> > >> 3261 that specifies this is intended for unreliable
> > provisionals, but
> > >> has been interpreted to also be possible when there was 
> a reliable 
> > >> response with an answer. But I can find no rationale for
> > allowing an
> > >> offer that was sent in a reliable provisional to be sent
> > again in the
> > >> 200 response to the invite.
> > > 
> > > Since SIP only allows at most one o/a exchange per SIP
> > transaction, I think the o/a state machine should know that 
> the SDP in 
> > 200 is of no meaning - no matter if it's a copy of a 
> previously sent 
> > (in a reliable 18x) offer or anwer.
> > > 
> > > It's the same thing if you send an offer, or answer, in a
> > reliable 18x, and then copy it in subsequent reliable 18x responses 
> > for the same transaction - from an o/a perspective they have no 
> > meaning.
> > > 
> > > 
> > >> Also I can find no rationale for allowing a *new* offer to be 
> > >> included in the 200 response to an invite if the initial
> > o/a has been completed.
> > > 
> > > Correct. Again, at most one o/a exchange per SIP
> > transaction. Keeping
> > > that in mind will take you pretty far, I think :)
> > > 
> > > 
> > >>> 2. If 200 in F5 carries the same SDP with that in 18X, 
> should UAC 
> > >>> send an ACK with SDP?
> > >>>
> > >> Definitely not.
> > > 
> > > Agree.
> > > 
> > > Regards,
> > > 
> > > Christer
> > > 
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> > > 
> > 
> 
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to