Subject: [SIP] received parameter is invalid

From: Gethin Liddell <[email-masked]>
Date: Fri, 4 Aug 2000 15:32:56 +0100

um, hello

i've just noticed that the much loved and adored received parameter
does not actually obey the generic-param syntax:

generic-param: token=token|quoted-string

received=host[:port]

the problem is that : is not a token and so received does not conform.

can we make : a token? or does that ruin other stuff.  i've had a quick
look (by no means through) and couldn't find any conflicts.

or do we leave it as it is and have the attitude that everyone should
know of the received parameter and how to parse it.

it would have been nice to handle the un-encrypted and encrypted
received parameter the same way (i.e. just read a token and then
un-encrypt it if neccessary) however this does not allow that.

thoughts?

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Aug 2000 11:56:01 -0400

That's indeed bad, since it may break generic parsers. Since the port is
not in RFC 2543, might it make sense to define received-port as a
parameter.

I don't want to extend token since that would conflict with RFC 822 and
RFC 2616.

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 04 Aug 2000 11:50:49 -0400

It seems I missed the moment when [:port] was added to "received". What
problem is it supposed to solve? 

Firstly, the source port is quite likely to be different from the one
listed in Via even without the NAT and the "received" most certainly
should not be added in that case. Secondly, the latest 2543bis I could
find is not very consistent on the subject: 6.47.2 first says that
"received" is added when the source address doesn't match the address in
the Via, next that it's added iff source address _and_ port differ from
the ones in Via.

Besides, if you use the NAPT, specifying the port in "received" doesn't
help. In any case, just correcting Via is not very helpful for NAT
traversing (e.g., how are you going to send re-INVITEs or BYEs in the
reverse direction?) so I'd rather keep the "received" parameter as
simple as possible (i.e., leave it the way it's defined in RFC2543).

Thank you,
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Aug 2000 12:07:00 -0400

Mindo on my part. This was a failed attempt to deal with NA(P)T. Thus,
it should be gone not just for syntax reasons.