Subject: [Sipping] URI parameters and draft-burger-sipping-netann-05

From: [email-masked]
Date: Fri, 14 Mar 2003 12:11:12 +0100

Eric , Dear SIPPING members,
In the network model on which is based  the draft-burger-sipping-netann-05,
do you make the assumption that the proxy that requires announcement
playing
to the media server  is the "last hop" proxy?

In case , not, we have the risk that  the proxies that are on the path to
the media server,
may change or remove the uri parameters that describes the annoucemement.

I say so,because  in RFC 3261, It is not guarantied that a proxy copies
"transparently"
the URI parameters in the forwarded request (am I right?)

So I have a more general question. Should announcement description be
included in uri parameters?
shouldn't user part be a better place for this?

Thanks for your help

Pascal

_______________________________________________
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: "James Undery" <[email-masked]>
Date: Fri, 14 Mar 2003 14:07:10 -0000

Comment inline
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; "Eric Burger" <[email-masked]>
Sent: Friday, March 14, 2003 11:11 AM
Subject: [Sipping] URI parameters and draft-burger-sipping-netann-05

> the URI parameters in the forwarded request (am I right?)

No you are wrong, RFC3261 states that a proxy that isn't responsible (i.e.
knows the location server) for the domain/IP of the request URI shouldn't
change the request URI this includes parameters that it doesn't know about.
As the request URI should be targeted at the media server (or else how will
it get there) intermediate proxies should not change or strip parameters.

> shouldn't user part be a better place for this?

In order to work with RFC 2543 or misbehaving proxies this may seem a better
idea, but it seriously impacts how a location service would work with
multiple media servers and just seems philosophically wrong. IIRC this was
the subject of much debate when this draft was first presented.

James