asterisk users - Mar 2006 - Confusion about construction of RURIs from contact headers for BYEs generated by *

I'm a bit confused about how * constructs the RURI when it generates a
BYE. For the situation where * send the initial INVITE it constructs the
RURI for the BYE from the contact header of the 200 OK response which is
well and good. However when * receives the initial INVITE it does not
use the contact header contained within to construct the BYE's RURI but
constructs it from scratch. This is of particular concern when one is
using a SIP clients that only do TCP like office communicator (and of
course a proxy in the middle to do UDP/TCP protocol conversion) . In
these cases well-behaving UA puts a transport=tcp tag into the contact
header of either the INVITE or the 200 OK. In the first scenario this
tag is preserved and the BYE's RURI has the transport tag (which the
proxy can use for protocol conversion). The second scenario loses the
transport tag in the BYE's RURI (and the proxy has no idea that protocol
conversion is needed)

Is my understanding  of the code correct and if so was this something
that was just missed or a design decision.


-- 
Dr. Rodney G. McDuff                 |Ex ignorantia ad sapientiam
Manager, Strategic Technologies Group|    Ex luce ad tenebras
Information Technology Services      |
The University of Queensland         |
EMAIL: mcduff@its.uq.edu.au          |
TELEPHONE: +61 7 3365 8220           |

7 mar 2006 kl. 03.15 skrev Dr. Rodney G. McDuff:
> I'm a bit confused about how * constructs the RURI when it generates a
> BYE. For the situation where * send the initial INVITE it  
> constructs the
> RURI for the BYE from the contact header of the 200 OK response  
> which is
> well and good. However when * receives the initial INVITE it does not
> use the contact header contained within to construct the BYE's RURI  
> but
> constructs it from scratch. This is of particular concern when one is
> using a SIP clients that only do TCP like office communicator (and of
> course a proxy in the middle to do UDP/TCP protocol conversion) . In
> these cases well-behaving UA puts a transport=tcp tag into the contact
> header of either the INVITE or the 200 OK. In the first scenario this
> tag is preserved and the BYE's RURI has the transport tag (which the
> proxy can use for protocol conversion). The second scenario loses the
> transport tag in the BYE's RURI (and the proxy has no idea that  
> protocol
> conversion is needed)
>
> Is my understanding  of the code correct and if so was this something
> that was just missed or a design decision.
>
This seems to be a bug we have to fix. Some advice:

- Please do not crosspost to two mailing lists
- Always mention version of Asterisk you are using when reporting a  
problem
- Open a bug report for this in the bug tracker, bugs.digium.com

Thanks
/Olle

7 mar 2006 kl. 03.15 skrev Dr. Rodney G. McDuff:
> I'm a bit confused about how * constructs the RURI when it generates a
> BYE. For the situation where * send the initial INVITE it  
> constructs the
> RURI for the BYE from the contact header of the 200 OK response  
> which is
> well and good. However when * receives the initial INVITE it does not
> use the contact header contained within to construct the BYE's RURI  
> but
> constructs it from scratch. This is of particular concern when one is
> using a SIP clients that only do TCP like office communicator (and of
> course a proxy in the middle to do UDP/TCP protocol conversion) . In
> these cases well-behaving UA puts a transport=tcp tag into the contact
> header of either the INVITE or the 200 OK. In the first scenario this
> tag is preserved and the BYE's RURI has the transport tag (which the
> proxy can use for protocol conversion). The second scenario loses the
> transport tag in the BYE's RURI (and the proxy has no idea that  
> protocol
> conversion is needed)
>
> Is my understanding  of the code correct and if so was this something
> that was just missed or a design decision.
>
This seems to be a bug we have to fix. Some advice:

- Please do not crosspost to two mailing lists
- Always mention version of Asterisk you are using when reporting a  
problem
- Open a bug report for this in the bug tracker, bugs.digium.com

Thanks
/Olle



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev