Subject: RE: [Sipping] New version of netann

From: "Eric Burger" <[email-masked]>
Date: Wed, 5 Mar 2003 08:36:10 -0500

Inline inline :-)

> Original Message From: Christer Holmberg 
> Hi Eric,
> 
> I haven't had time to look at the new version of the draft 
> yet, but I'd like to comment my comments :)
> 
> > "Early" URI Parameter
> > =====================
> > Christer Holmberg pointed out his preference for coming up 
> with a generic "this session is early" mechanism.  At this 
> time, I'm not sure that this is something that occurs in 
> other situations.  Given that, we've left in the early parameter.
> 
> [CHH] I think that early media DO occur in other situations 
> (at least in PSTN interworking). At least I assume so, since 
> there has been much discussion about it lately...
> 

If we can make this mechanism generic, that would be great.  I don't see how we can figure that out except for an explicit mechanism.

As an explicit mechanism, it could be a parameter or a header.  For some reason I have an aversion to inserting a new header, but I could be convinced to get over that phobia.

> > I would agree that the UAC might not support early media.  
> However, the onus would be on the proxy, not the media 
> server, to enforce 100rel.  If the UAC doesn't support 
> 100rel, then the proxy should request it.
> 
> [CHH] Do you mean that the proxy is going to insert Require: 
> 100rel in the request, then handle the sending of PRACK, and 
> make sure that retransmissions of 18x messages received by 
> that proxy aren't forwarded back to the UAC, etc etc?
> 
> Or, do you mean that the proxy will send a 421 Extension 
> Required response back to the UAC?

The latter (421 Extension Required).  In this case, signaling works :-)
_______________________________________________
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 <[email-masked]>
Date: Wed, 05 Mar 2003 19:27:57 +0200

Hi Eric,

> As an explicit mechanism, it could be a parameter or a header.  For some reason I have an aversion to inserting a new header, but I could be convinced to get over that phobia.

Have you read the latest version of Gonzalo's early media draft? How would that fit into this?

> The latter (421 Extension Required).  In this case, signaling works :-)

Which means that a UAC MUST support PRACK, instead of SHOULD, right?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 05 Mar 2003 21:19:02 +0200

Hi Eric,

A question on the draft, related to the functionality.

Assuming there is a media stream service which consists of both audio and video, identified with different promt-urls, do I have to send separate INVITEs for those (in RTSP
separate SETUPs and PLAY are sent)? Or, is it possible to include multiple play parameters in a single INVITE Request-URI?

Regards,

Christer Holmberg
Ericsson Finland