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

From: "Attila Sipos" <[email-masked]>
Date: Tue, 13 Feb 2007 13:44:59 -0000

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

Is this really going to work?
If it works, it is just luck I think.
In RFC 3261 it says...

             The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

So should lack of SDP get ignored?
Intuitively I would say yes.

Isn't UPDATE the only legal way for the fake fork
to say "don't talk or listen to me"?

Regards,

Attila

-----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
inearlymedia: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).

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

_______________________________________________
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 14:58:20 +0100

>>>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
> 
>Isn't UPDATE the only legal way for the fake fork to say 
>"don't talk or listen to me"?

An UPDATE could work in the case where the B2BUA establishes a dialog,
because the B2BUA acts as the UAS.

But, in real forking cases you can't expect the end-terminal UAS to send
an UPDATE (e.g. if they don't accept a call and will send an error
response), so the forking proxy would have to do it - which would mean
it becomes a B2BUA. I think it would be much easier for the forking
proxy to simply send a 19x.

Regards,

Christer

> To: Christer Holmberg (JO/LMF); Elwell, John; Paul Kyzivat; 
> Siddhartha Bhakta
> 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
>

---

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

>          session descriptions in subsequent responses to the initial

Whether it says it or not, the above is intended to apply *per dialog*. 
Each early dialog is handled independently.

It would be applicable if the 190 carried a session description. I 
haven't seen, or don't recall, the specifics of what had been proposed 
for the 190, so I don't know if it depended on a session description or not.

> to say "don't talk or listen to me"?

My impression is that the intent is to say: "this early dialog is 
ended". It has to be something <200 so that it can be returned while 
allowing the other forks to proceed.

	Paul

---

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

Hi, 

>It would be applicable if the 190 carried a session description. I
haven't seen, or don't recall, the specifics 
>of what had been proposed for the 190, so I don't know if it depended
on a session description or not.

Well, the first time I brought it up it was shot down before we even
started the discussions on the details :)

Regards,

Christer

> My impression is that the intent is to say: "this early 
> dialog is ended". It has to be something <200 so that it can 
> be returned while allowing the other forks to proceed.
> 
> 	Paul
> 
> > Regards,
> > 
> > Attila
> > 
> > 
> Siddhartha 
> > 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.
> > 
> from the 
> endpoint no 
> > What would be nice is if each dialog was handled explicitly, rather 
> > than implicitly at the originator for early media (i.e. the 
> originator 
> > 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
> > 
>