Subject: RE: [Sip] Open Issue #203: transport related params in To/From

From: Eric Tremblay <[email-masked]>
Date: Thu, 28 Mar 2002 13:09:35 -0500

Ouch! This one fell through the cracks, and I'm surprised it did not
generate more comments. I know it's kind of late to comment on that and I
don't expect any changes, but I want to make sure I understand a few things.

1- Bis06 and later won't interoperate with Bis05 and earlier if Bis05
devices add ports to their From/To headers of their requests. (the port can
get stripped in the response, causing a failure to match the response to the
request). Our devices are placing the port number in From/To if the home
server is listening to something else than 5060 :( Of course, if the Bis06+
device echo the port in responses, everything should work fine.

2- I thought that when I was sending an INVITE to establish a dialog, the
URL found in the From: could be used to call me back later on. This URL
usually pointed to my home server. If this server has no SRV entries and if
it is using a port different than 5060, there is no way for the user I have
called to call me back. Am I right?  It should work fine as long as SRV
records are used.

Am I right on the two counts?

Regards,

EricT

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, December 27, 2001 2:14
To: Jo Hornsby
Cc: Robert Sparks; [email-masked]
Subject: Re: [Sip] Open Issue #203: transport related params in To/From

There was one email on this thread supporting the proposal, and the rest 
of the thread dealt with additional wording that might have to be added 
in support of it.

I will comment on the extra wording bits below, but otherwise, I believe 
there is consensus to accept the proposal. In that case, port and maddr 
are disallowed from the To/From URLs.

More comments below.

Jo Hornsby wrote:

> Robert wrote:
> 
>>>>Issue:
>>>>
>>>>Minor issue. Table 1 indicates that in the From/To fields, a 
>>>>SIP URL cannot contain an maddr, but can contain a port.
>>>>This seems odd. Either all addressing params should be 
>>>>allowed (port, transport, ttl, maddr) else none of them.
>>>>
>>>>Proposal:
>>>>
>>>>From/To are supposed to be logical addresses, so neither port 
>>>>nor maddr nor any of the others make much sense there.
>>>>Proposal is to remove unless anyone is sending with these
>>>>parameters.
>>>>
>>>Sounds good to me.
>>>
>>>If this approach is adopted, am I right in thinking we will
>>>have to be _very_ strict about refusing requests that have
>>>these parameters (else I can see nasty SIP URL comparison
>>>issues ariving)?
>>>
>>Why not ignore them if present? I can't think of any comparison
>>issues taking that approach that don't also exist in deciding to
>>reject the message based on the contents of the URL.
>>
> 
> I think what I was envisaging was some entity on
> the network ignoring these parameters, and then
> due to some sort of weird transaction keying
> interaction, actually removing them when it
> responded or proxied sommat.

In this context, having these parameters be "disallowed" means they MUST 
NOT be inserted, and MUST be ignored by any element that receives them 
there. So, to be honest, if you do put them in the To field, and the 
result is that they get stripped when they come back to you, well, thats 
your problem. Bets are off when you send invalid messages. An 
implementation might be nice enough to handle it anyway for you, but its 
not something the spec would mandate.

> Also, if we take the approach that they should
> just be ignored, then what happens if two requests
> arrive that are otherwise identical apart from the
> port in the To:, say?

They are identical.

-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

_______________________________________________
Sip mailing list  http://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

_______________________________________________
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