Subject: [Sip] Open Issue #268 : port number and maddr

From: Robert Sparks <[email-masked]>
Date: Wed, 23 Jan 2002 12:56:10 -0500

This open issue has not been directly addressed on the list,
but it has been touched on in several threads over the last
few months. It has some impact on the looseroute proposal.

Issue: What do the transport and port paramters on a SIP URI
       mean when an maddr parameter is present? Do they refer
       to the next hop or to the element ultimately responsible
       for the resource?

Discussion: 
 The maddr parameter has been used in several places to cause
 a request to be delivered to an address other than what would
 normally be derived from processing the remainder of a URI (such
 as the hostpart).

 For instance:
 UAC          1.2.3.4       foo.com
  | INVITE sip:[email-masked];maddr=1.2.3.4
  |-------------->|            |
  |               |INVITE sip:[email-masked]
  |               |----------->|

 What does it mean when the first URI contains a port or 
 transport parameter? For example:

 UAC          1.2.3.4       foo.com
  | INVITE sip:[email-masked]:6666;transport=tls;maddr=1.2.3.4
  |-------------->|            |

 What do the parameters mean to 1.2.3.4?  Do they describe a port
 and transport to be reached at 1.2.3.4 or at foo.com? Obviously,
 they can't describe both.

 To be consistent with the historic mechanisms for determining 
 where to send requests, and the procedures documented in sip-srv,
 they must be interpreted as describing how to reach 1.2.3.4.
 
 The penalty is that you can't then use maddr to cause a request
 to be routed through a proxy to a destination with a non-default
 port or transport. This isn't pretty, but it also isn't as limiting
 as it might seem at first. Almost everywhere maddr is currently
 being used, it is provided by the element responsible for the
 address it specifies (record-route for example). That element
 can also specify alternate ports and transports. Loose-routing
 elements don't need it - they just send the message to the address:port
 using the transport their policy dictates. They can also fully specify the
 address:port:transport of more than one place to visit by pushing Route
 header values. 

 The only problem we have is that this interacts badly with the algorithm
 proposed in the looseroute draft for making the topmost Route header
 and the Request-URI sufficiently different to avoid inducing a
loop-detection
 if the next hop just happens to be a strict-routing loop-detector.
 I'll be posting a discussion of that problem and an alternate solution
 shortly.

Proposed Resolution:

 If a port or transport parameter is specified in a URL that contains
 an maddr parameter, the port and transport apply to the address indicated
 by the maddr parameter value.

 So, the flow above would continue
 UAC          1.2.3.4       foo.com
  | INVITE sip:[email-masked]:6666;transport=tls;maddr=1.2.3.4
  |-------------->|            |
  |               | INVITE sip:[email-masked]
  |               |----------->|

assuming 1.2.3.4 received the message over tls at port 6666.
If 1.2.3.4 recieved the message on some other port or using
some other transport, it would forward the message to port
6666 at 1.2.3.4 over tls.

I am documenting this in bis now. Please comment quickly.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 23 Jan 2002 14:49:53 -0600

Response inline...

>        to the next hop or to the element ultimately responsible
[...]
>  an maddr parameter, the port and transport apply to the address 
>  indicated by the maddr parameter value.

This is the existing behavior, if I am not mistaken.

>   | INVITE sip:[email-masked]:6666;transport=tls;maddr=1.2.3.4

I have no  problems with the resolution.  However, would something
like this be entertained: 

  INVITE sip:[email-masked]:7777;maddr=1.2.3.4:9999:tls

In other words, the maddr will have 2 optional values, separated by :.  
Here, port 7777 affects foo.com and port 9999 affects 1.2.3.4.

While this has the nice property that all factors that affect maddr are
in the maddr parameter, the biggest disadvantage is that it is NOT 
backward compatible.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 15:18:21 -0500

Vijay Gurbani wrote:

> in the maddr parameter, the biggest disadvantage is that it is NOT

I'm going to take this moment to describe our basic aim with "backwards
compatibility" for SIP.

First off, the primary aim is NOT backwards compatibility with 2543, but
backwards compatibility with existing implementations, with greater
concern for things that are deployed or cannot be easily changed with
any speed.

Second, there are definitely cases where we have lost interop -
generally, under specific conditions and scenarios, something stops
working. I think it is acceptable to lose such interop when the
conditions or scenarios are deemed sufficiently unlikely. However, a
change which means that failure will occur in all scenarios, that is not
acceptable.

Unfortunately, that is the case with Vijay's proposal above. It has been
proposed before at least a few times before, and still has the same
problem now it had then. It breaks in all cases.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com