Subject: RE: [Sipping] Early media; philosophical discussion

From: "Francois Audet" <[email-masked]>
Date: Mon, 7 Apr 2003 17:58:07 -0700

What I am proposing is that there should be a mechanism in the INVITE to
tell the 
gateway NOT to provide early media (at least for ringing). This would solve
a lot of 
problems including the forking problem.

I don't see why this would be difficult to do. There is no such thing as
early ringing media that is essential to the call when forking occurs
because
the endpoint receiving it will not be able to play it.

The gateway would do one of the following upon receiving the
no-early-ringing
indication:

1 - Not send early ringing if it knows he difference between early ringing
    and early media-to-avoid-clipping. This is possible only in certain
cases,
    for example when the gateway itself is providing the ringing (for
example
    if the gateway is a PBX or Public Exchange and the call terminates to a 
    phone on the switch). This method when applicable, is preferred because 
    it will avoid any possibility of clipping the "hello".

2 - Not send any early media at all. This is when the gateway does not know
    the difference between early ringing and early media-to-avoid-clipping 
    (for example, when the media is provide by another circuit-switch
upstream,
    when there is tandeming over the PSTN). The gateway will only
"cut-through" 
    when the connection indication is received. Note that there is a
possibility 
    of clipping part of the "hello" under certain circumstances (as we
discussed 
    earlier): however, this possibility would happen anyways since there is
no 
    way for the receiver to distinguish between various overlapping streams.

And yes, for the Native SIP (non-gateway) early media, we could use your
application 
server model. I agree on that (although it would be nice if we didn't need
to include
the join header in all calls, and if somehow the application server could
handle it).

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Friday, April 04, 2003 22:16
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Christer Holmberg'; Watson, Mark [MOP:EP10:EXCH]; 
> Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]'; 'Jon Peterson'
> Subject: Re: [Sipping] Early media; philosophical discussion
> 
> 
> Francois,
> 
> I have already answered this one in another note (I believe I sent it 
> yesterday). The gateway model is appropriate when the UAS is 
> not the one 
> "generating" the early media. This means that, a gateway cannot know 
> whether the early media is optional or not. A gateway does not know 
> whether the early media it is receiving from the 
> circuit-switched part 
> is optional or is essential to the call. Therefore, even if 
> this gateway 
> receives an indication from in the INVITE saying that the requested 
> forked, the gateway CANNOT DO ANYTHING. It needs to send the 
> media anyway.
> 
> However, a pure SIP UAS knows that what it is about to generate is a 
> message that says "Thanks for calling Francois, please wait". 
> Therefore, 
> it sends a separate INVITE (application server model), which 
> the UAC can 
> refuse if it is already overloaded with other stuff.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 08 Apr 2003 09:11:22 +0300

Hi,

Just to clairfy your proposal:

Since the UAC gateway most likely doesn't know if an INVITE is going to
be forked, I assume it would ALWAYS insert this "don't-send-early-media"
flag in the INVITE, right? Now, if the UAS is also a gateway (trunking
scenario) it would very often not send early media, because it doesn't
know the difference you described. So, in this case the early media from
one PSTN network would not be sent to the other PSTN network.

Or, did I missunderstand your mail?

Regards,

Christer Holmberg
Ericsson Finland

Francois Audet wrote:

>
>
> What I am proposing is that there should be a mechanism in the INVITE
> to tell the
> gateway NOT to provide early media (at least for ringing). This would
> solve a lot of
>     and early media-to-avoid-clipping. This is possible only in
> certain cases,
>     earlier): however, this possibility would happen anyways since
> there is no
> And yes, for the Native SIP (non-gateway) early media, we could use
> your application
> server model. I agree on that (although it would be nice if we didn't
> need to include
> the join header in all calls, and if somehow the application server
> could handle it).
>

_______________________________________________
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