Subject: [SIP] removing transport, maddr and port from request URI (was RE: [SIP ] Request-uri does not match record-route header...)

From: Igor Slepchin <[email-masked]>
Date: Wed, 25 Apr 2001 12:09:37 -0400

I actually wanted to discuss this for quite some time now so here it goes.

I do believe that maddr, transport and port should be removed from the
request URI unless they are intended to be used for routing by the
downstream SIP entities. In other words, if you are forwarding a request
based on the information supplied in maddr, port or transport, you should
remove that information from the request URI before forwarding the request.

Here is the motivation. All components of request URI may be used for
routing by the downstream proxies. Keeping the parameters that should
_never_ be used for routing seems to contradict that assumption and sounds
rather weird to me; in the worst case scenario, this may even cause
unintended loops (e.g., if a proxy somewhere downstream suddenly decides to
honor an maddr pointing to the local outbound proxy of the UAC). On the
other hand, removing them if they are no longer needed is always safe.

What do people think?

Thank you,
Igor Slepchin

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Thursday, April 19, 2001 6:33 AM
> To: Pekka Pessi; [email-masked]
> Cc: Fairlie-Cuninghame, Robert
> Subject: RE: [SIP] Request-uri does not match record-route header...
> 
> 
> >         Proxies should always use the next route header. 
> > 
> >         However, there is a problem if the initial RequestURI and 
> >         the first
> >         url in the route are identical (sans maddr and 
> other transport
> >         parameters, which are removed by sender).
> 
> Uh, at the risk that this is orthoganol to the issue at hand,
> why would these parameters be removed?  Note that they're no-
> longer illegal in the Request-URI (I think they were in RFC).
> 
> 
>  - Jo.
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.