You've also got your bottom-posting order in the wrong order. :-)
As far as I know, things that are separated by ";" characters can be moved around each other; ordering should not be important. I can't find the RFC that says this, so I'm possibly wrong with this.
I will say that every example I can find has "rport" right after the IP address (as in your example #6 below.) I don't know if Asterisk supports the "rport=<number>" options, either.
Let us know of the results of your experiment. If the Uniden works after you move things around, I think a ticket should be opened (by you, since you'll have the empirical data) to suggest a change to Asterisk so that it sends the "expected" ordering (even though it perhaps shouldn't matter.)
JT
At 1:50 PM -0600 on 6/25/04, Ryan Courtnage wrote:
Hmmm, I think * may have the syntax wrong:
from http://www.ietf.org/rfc/rfc3581.txt :
----snip---- 5. Syntax
The syntax for the "rport" parameter is:
response-port = "rport" [EQUAL 1*DIGIT]
This extends the existing definition of the Via header field parameters, so that its BNF now looks like:
via-params = via-ttl / via-maddr / via-received / via-branch / response-port / via-extension
6. Example
A client sends an INVITE to a proxy server which looks like, in part:
INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff ----snip----
* is sending as:
Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
ie: rport is in the wrong spot. Don't know this makes a difference.
I'll try hacking chan_sip.c myself to see if the order of the parameters matter.
Ryan
On Friday 25 June 2004 12:44, Ryan Courtnage wrote:Hi,
Bug #1862 implemented RFC3581.
I'm no expert, but it appears that this change appends ";rport" to the end of the VIA header field on INVITEs sent to SIP phones:
Message Header Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
Problem is, this breaks dialing to Uniden UIP200 phones (they don't reply back when the Via header has ";rport" on the end).
So, do I need to put pressure on Uniden to fix this, or has RFC2581 been implemented in * incorrectly ?
Thanks for any help on this - I'm currently stuck using * builds previous to Bug #1862.
Ryan
PS: I'm usind nat=no ... if that matters.
-- .................................. Ryan Courtnage Coalescent Systems Inc 403.244.8089 www.voxbox.ca _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev_______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
