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

From: "Francois Audet" <[email-masked]>
Date: Tue, 8 Apr 2003 11:11:59 -0700

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]] 

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

Almost. I'm saying that the UAC would NOT include the
don't-send-early-media-
for-ringing flag in the INVITE. They'd be no change on the UAC, and that's
why
it is backward compatible.

A forking proxy would normally include the
don't-send-early-media-for-ringing flag
in the INVITE. 

This is why this indication can NOT be at the SDP level because the proxies
can't
touch it. Bill, if for whatever reason, the UAC does not want early media,
than
it would indeed use RFC 3312. But the proxy can certainly not use it.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 08 Apr 2003 21:16:04 +0300

Hi,

> for-ringing flag in the INVITE. They'd be no change on the UAC, and
> that's why

Well, if the INVITE reaches another gateway the result would still be
the same. Early media from the remote PSTN network would not be
forwarded, and would not reach the UAC gateway and the PSTN network
behind it.

Regards,

Christer Holmberg
Ericsson Finland

>
>
> This is why this indication can NOT be at the SDP level because the
> proxies can't
> touch it. Bill, if for whatever reason, the UAC does not want early
> media, than

_______________________________________________
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