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

From: Siddhartha Bhakta <[email-masked]>
Date: Sun, 12 Nov 2006 19:03:49 +0000 (GMT)

Hi,

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 Bhakta

__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

_______________________________________________
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: Siddhartha Bhakta <[email-masked]>
Date: Sun, 12 Nov 2006 19:11:14 +0000 (GMT)

I am re-sending it as in last email, the figure was
distorted.

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

The sec 2.2. of

Thanks & Regards,
Siddhartha

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 12 Nov 2006 21:39:39 -0500

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
>

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Mon, 13 Nov 2006 11:47:59 -0000

I know, the RFC3261 indicates so. As per RFC3261, all such 1xx with SDP
should contain distinct to-tags(virtual UAS) so that it appears to belong to
different dialogs. The offer-answer state is maintained separately in
different dialogs. Therefore, there shall not be the case where a single
dialog is having multiple answers for a single offer.

However, we can not deny the fact that this flow of RFC3261/RFC3264 is not
backward compatible (where multiple SDP answers were possible per SDP
offer). In my depicted example, the 183 shall definitely have different
to-tag. But the '180 Ringing' shall carry same to-tag as that of 200 OK. So
my concern is that whether we should put the effort to make RFC3261/RFRC3264
backward compatible. I hope, this is quite justifies expectation.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 13 November 2006 02:40
To: 'Siddhartha Bhakta'; [email-masked]
Cc: 'Siddhartha Bhakta'
Subject: RE: [SIPPING] SDP offer/answer in early
media:draft-sawada-sipping-sip-offeranswer-01.txt

-hadriel

>   |   183 F3   |----------->| INVITE F4  |

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 12:50:35 -0500

>   |   183 F3   |----------->| INVITE F4  |

In the above, F3 is illegal according to 3261, because this action is 
not permitted for proxies. It can be fixed by modeling another UA (an 
early media source) that the proxy forks to.

F6 may also be illegal. It depends on whether the PABX is a proxy or a 
B2BUA. If a proxy then it too is illegal.

> as far as B2BUA is concerned.

This is not required if F3, F7, and F10 are all separate dialogs. If I 
understand what you are trying to accomplish, then that is the way to 
accomplish it.

> Therefore, B2BUA shall

If the three SDPs are generated independently then they can't be 
expected to obey the constraints imposed by being within a single 
dialog. Your problem is trying to force them to do so.

> be used to update the media in early media.

That would not solve your problem. It is concerned with a single dialog. 
You have a situation with multiple dialogs. Each must be considered 
separately.

(However, you are not the first to raise this sort of issue. Perhaps it 
should be discussed in the draft.)

> But in

> of it then I may comeup with some thumb rule for the

IMO there is nothing to fix in the standards to solve your problem. What 
needs fixing are the sip implementations in some of the elements you are 
using.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 13:17:57 -0500

Siddhartha Bhakta wrote:
> offer).

I beg to differ. In fact I *do* deny your assertion.

> In my depicted example, the 183 shall definitely have different
> to-tag. But the '180 Ringing' shall carry same to-tag as that of 200 OK.

Well, the 180 F5 presumably has the same to-tag as 200 F8. But 180 F6 is 
a different message that F5. It has SDP from a different source. So it 
should have a different to-tag from both F3 and F5.

It is clearly a matter for your PABX to decide how to handle F9.

> So

You just need to make your implementations backwards compatble with 3261 
and 3264.

	Paul

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Mon, 13 Nov 2006 18:19:27 -0000

Paul,

The proxy and PABX in my figure are acting perfectly fine with the RFC2543
standard or any old standard that allows the PSTN like early-media flow. In
those standards, multiple SDP answer of a single SDP was allowed.

As soon as we upgrade our node to RFC3261, we are facing this problem.

Can I say the offer/answer flow of RFC3261/RFC3264 is not backward
compatible to older early-media standard?

If that is the case, then I believe, we should try to make RFC3261/RFC3264
backward compatible otherwise people shall definitely face this problem. I
thought, this draft shall be best place to address this issue.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 13 November 2006 17:51
To: Siddhartha Bhakta
Cc: [email-masked]; Siddhartha Bhakta
Subject: Re: [SIPPING] SDP offer/answer in early media:
draft-sawada-sipping-sip-offeranswer-01.txt

	Paul

---------------

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 13:42:19 -0500

> As soon as we upgrade our node to RFC3261, we are facing this problem.

Ah! This is the first time you have mentioned 2543. If it is 
compatibility with 2543 that you are concerned with, that is an entirely 
different story. And it is one that is largely not discussed in 3261, 
though 3261 took some pains to allow coexistence.

Its been a very long time since I looked at 2543, so I won't claim to be 
able to give you an accurate answer with respect to that. In particular, 
I am not going to go digging to figure out whether what you are showing 
would be valid in 2543 or not.

For the most part people now assume 3261 support, so you may have 
difficulty getting help with questions on 2543 compatibility.

In any case, I disagree that your proxy is compliant with 2543. I'm 
pretty sure that even back then proxies were not allowed to generate an 
answer to an offer - that is a UA responsibility.

> compatible to older early-media standard?

I wasn't around when the backward compatibility issues of this were 
worked out, so somebody else will have to answer to that.

> thought, this draft shall be best place to address this issue.

If there was a problem, it should have been caught before 3261 became an 
RFC. It has been an RFC so long, with so many implementations, that 
incompatible changes to it would be worse than the incompatibility with 
2543.

	Paul

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Tue, 14 Nov 2006 12:13:20 -0000

Paul,

The PABX in my example is a B2BUA. But 180(F6) and 200(F9) generated by it
is having same to-tag but they are carrying different SDPs. The PABX vendors
are claiming that below mentioned flow is as per RFC2543. I could not
counter it as I could not find out the reference where RFC2543 is preventing
it.

For a Media server(IVR) implementation, the tone (183) and voice (200) might
contain different media description as that were not prevented in RFC2543.
The RFC2543 compliant Media server shall not put different to-tag in 183 and
200 for sure as it is not the forking case. Now, if any RFC3261 compliant
phone does not apply SDP of 200 OK then it can not hear the voice.

Now, it's down to the fact whether RFC3261 supports the co-existence to
RFC2543 or not. I hope, I am not the only one who faced this problem. We are
going beyond RFC3261 (in our implementation) to support the co-existence of
RFC3261 and RFC2543. But it would have been better if RFC3261 itself could
have addressed this.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 13 November 2006 18:42
To: Siddhartha Bhakta
Cc: 'Siddhartha Bhakta'; [email-masked]
Subject: Re: [SIPPING] SDP offer/answer in early media:

	Paul

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

---------------

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 14 Nov 2006 10:38:38 -0500

> The PABX in my example is a B2BUA. But 180(F6) and 200(F9) 
> generated by it is having same to-tag but they are carrying 
> different SDPs. The PABX vendors are claiming that below 
> mentioned flow is as per RFC2543. I could not counter it as I 
> could not find out the reference where RFC2543 is preventing it.

It was considered that rfc2543 allowed too much flexibility/ambiguity
from an SDP offer/answer perspective; and thus it was considered not
interoperable.  Subsequent drafts reduced much of the
flexibility/ambiguity and that was what many vendors implemented.

For better or worse, rfc3261 (and other offer/answer RFCs) removed even
more of the flexibility.

<snip>

> Now, it's down to the fact whether RFC3261 supports the 
> co-existence to RFC2543 or not. I hope, I am not the 
> only one who faced this problem. We are going 
> beyond RFC3261 (in our implementation) 
> to support the co-existence of RFC3261 and RFC2543. 
> But it would have been better if RFC3261 
> itself could have addressed this.

I agree.  However many considered rfc2543's ambiguity/flexibility
unworkable; thus there was little associated backward compatibility
consideration given to rfc2543.  As you are experiencing, a large
complaint with rfc3261 was not allowing the SDPs to change (and not be
ignored) within subsequent 18x's and 2xx.  When rfc3311 and rfc3262 not
supported/adequate and such SDP modification is desired, it forces
forking proxy simulations to remain compliant to rfc3261 and rfc3264.

Without the caller relaxing some of the offer/answer rules of rfc3261,
rfc3264, etcetera, it will have problems interacting with devices not
yet compliant.

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Tue, 14 Nov 2006 16:03:04 -0000

Thanks Brett. From your reply I could understand that the problem we are
facing is unavoidable. It is resulted not due to our lack of understanding
about RFC3261 but due to backward incompatibility of RFC3261 to RFC2543.

Thanks to Paul and Hadriel also for their time.

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: 14 November 2006 15:39
To: Siddhartha Bhakta
Cc: [email-masked]
Subject: RE: [SIPPING] SDP offer/answer in early

<snip>

---------------

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Nov 2006 18:55:43 -0600

> about RFC3261 but due to backward incompatibility of RFC3261 to  

I would actually say that it's more of a bug in RFC 2543, which  
wasn't even backward compatible with itself. It's much better  
specified in RFC 3261.

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 14 Nov 2006 17:25:56 -0800

> The PABX in my example is a B2BUA

This sounds not quite right.
 
A PBX is a call control server that has well defined SIP and RTP
behavior, while a B2BUA can be anything - great source of comfort :-)

It may be interesting to see if PBX developers agree with your
equivalence.

Henry

-----Original Message-----
From: Siddhartha Bhakta [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 6:13 AM
To: 'Paul Kyzivat'
Cc: [email-masked]; 'Siddhartha Bhakta'
Subject: RE: [SIPPING] SDP offer/answer in early

Paul,

The PABX in my example is a B2BUA. But 180(F6) and 200(F9) generated by
it
is having same to-tag but they are carrying different SDPs. The PABX
vendors
are claiming that below mentioned flow is as per RFC2543. I could not
counter it as I could not find out the reference where RFC2543 is
preventing
it.

For a Media server(IVR) implementation, the tone (183) and voice (200)
might
contain different media description as that were not prevented in
RFC2543.
The RFC2543 compliant Media server shall not put different to-tag in 183
and
200 for sure as it is not the forking case. Now, if any RFC3261
compliant
phone does not apply SDP of 200 OK then it can not hear the voice.

Now, it's down to the fact whether RFC3261 supports the co-existence to
RFC2543 or not. I hope, I am not the only one who faced this problem. We
are
going beyond RFC3261 (in our implementation) to support the co-existence
of
RFC3261 and RFC2543. But it would have been better if RFC3261 itself
could
have addressed this.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 13 November 2006 18:42
To: Siddhartha Bhakta
Cc: 'Siddhartha Bhakta'; [email-masked]
Subject: Re: [SIPPING] SDP offer/answer in early media:

Siddhartha Bhakta wrote:
> standard or any old standard that allows the PSTN like early-media
flow.
In

	Paul

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

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 16 Nov 2006 11:37:05 -0600

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 

> Sent: Sunday, November 12, 2006 8:40 PM
> 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
> 
> 
> > 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  |            |            |
> > 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.
> > 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.
> > 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
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Thu, 16 Nov 2006 17:58:16 -0000

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

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

Fake forking...

Regards,
Brian 

---------------

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 16 Nov 2006 12:03:45 -0600

Actually, I think you can.

Play out your early media as part of a separate dialog.

Regards,
Brian 

> From: Siddhartha Bhakta 
> [mailto:[email-masked]] 
> Sent: Thursday, November 16, 2006 11:58 AM
> To: Stucker, Brian (RICH1:AR00); 'Hadriel Kaplan'; 
> 'Siddhartha Bhakta'; [email-masked]
> 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 
> 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 
> 
> > 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.
> > 
> 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
> > 
> > 
> answer would be 
> > 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.
> ---------------
> 
>

---

From: Siddhartha Bhakta <[email-masked]>
Date: Thu, 16 Nov 2006 19:15:35 +0000 (GMT)

While UA is sending INVITE with SDP, it is listening
on the media port(s) published by it. If multiple
early media comes with different SDP description then
UA have to accept media from different destinations
irrespective of whether all these early media messages
are part of different dialogs or not.

However, as per RFC3264, offerer shall be able to
receive media packet before receiving SDP answer
(ofcourse, if offer media stream was
recvonly/sendrecv). Then, why is 18x (with SDP)
required? In early dialog, Media sending capability is
not required. The RTCP can be one of the reason! can
anyone confirm?

If 18x is not necessary then fake forking shall not be
required. Big relief :-)

Forget about the case, I was talking about for a
moment. If we take the fake forking case, in sec 2.9
of draft-ietf-sipping-service-examples-11. After
receiving F13 (180 ringing), which SDP shall be used
by Alice for media sending and RTCP purpose?
(given that Alice is receiving packet from both the
sources).

--- Brian Stucker <[email-masked]> wrote:

> [mailto:[email-masked]]
> > > >   |            |            |   180 without
> SDP F5
> > > > 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 
> indicates that UPDATE 
=== message truncated ===

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 14:58:09 -0500

> 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

---

From: Siddhartha Bhakta <[email-masked]>
Date: Sat, 25 Nov 2006 22:08:19 +0000 (GMT)

Brian,

The forking works fine with Local Ringback tone. New
proposal is only needed
to make early media work for forking. Most of the SIP
deployments are quite
happy with Local Ringback or Call progress tone.
Therefore UA may go ahead
with Local Ringback tone under forked condition if
in-band
early media is not absolutely necessary.
For forking condition if UAS wants to play early media
(i.e., in-band
call progress tone) then only they have to go ahead
with your proposal or
RFC3959.

The problem today is that UAS can not know whether
some incoming call is forked
or not therefore it don't know for sure whether it has
a (safe) choice of
going with traditional in-band early-media or not.
I am talking about the choice because Application
server model (RFC3959) or
your proposal may seems difficult for UAC to
implement.
Your proposal is definitely simpler than Application
server
due to that fact Application server introduces
multiple media sessions for
a single SIP dialog. The B2BUA in between or UAs may
find it difficult to
implement. Your proposal introduces multiple sessions
and dialogs for
a single call. UAC may look for choice of not
implementing it as they need
media mixing capability to implement your proposal.

Here is my proposal that gives the fare choice
depending on the situation:
	a)The UAC those have the ability to implement your
proposal (i.e.,
	  associated-media) shall indicate 
	  Content-Disposition: associated-media
	b)The forking proxy or B2BUA shall add a SIP header
namely 'forked'
	when it is forking

When INVITE reaches to UAS, depending on these two
parameters it can make
the choice.

Case1: Content-Disposition: associated-media and
forked header
	UAS may specify URL/URN (in 18x) of the media server
if it wants to
	feed in-band tone, music etc.
	UAS may also send 18x without SDP and it must not
send early media packet
	as this is forked call.

Case2:Content-Disposition: associated-media and
non-forked
   UAS may specify URL/URN for the media server in 18x
   UAS may send 18x with SDP and may start sending
in-band early media
   UAS may send 18x without SDP

Case3: No associated-media support and forked
   UAS MUST send 18x without SDP. Even if UAS wants to
play early media,
   it MUST not do so as it is forking call.

Case4: No associated-media support and non-forked
   UAS may send 18x with SDP and may start sending
in-band early media
   UAS may send 18x without SDP

Any comments?

PS: In my last email, I was describing the objective
of early of PSTN domain to check how much SIP domain
is fulfilling it. I was doing that since early-media
concept is inherited from PSTN domain. The objectives
are the a)call progess indication, b)Early indication
of the voice channel and c)no billing for early media.
I do agree with you that in SIP domain, end to end
early media is not quite common therefore b) objective
is hardly met. if we definitely solve the billing
problem then I think your proposal is giving a
powerful architecture. It will simplyfy early-media
flow for non-forking case also.