[Users] Re: [Devel] OperSER can't handle a maddr tag in the RURI

[Daniel-Constantin Mierla]

Hello,

On 03/07/06 02:00, Dr. Rodney G. McDuff wrote:
> Hi Daniel
> Daniel-Constantin Mierla wrote:
>   
>> Using subst_uri(), as you discovered, is the tweak to make it working
>> (see the mailing list archives). However, the contact in reply must be
>> handled by the end device (caller). The proxy should take care in case
>> of NAT.
>>     
> But would it be better to hide all these shenanigans from the user and
> just interpret the maddr tag instead of rewriting it
it makes sense, we will analyze the implications and include it on the 
to-do list.

Cheers,
Daniel

>  similar to how
> asterisk does it:
> >From chan_sip.c:
>   
>> /*! \brief  set_destination: Set destination from SIP URI ---*/
>> static void set_destination(struct sip_pvt *p, char *uri)
>> {
>>
>>     
> <snip>
>   
>>         /* Got the hostname:port - but maybe there's a "maddr=" to
>> override address? */
>>         maddr = strstr(h, "maddr=");
>>         if (maddr) {
>>                 maddr += 6;
>>                 hn = strspn(maddr, "0123456789.") + 1;
>>                 if (hn > sizeof(hostname)) hn = sizeof(hostname);
>>                 ast_copy_string(hostname, maddr, hn);
>>         }
>>     
>
>
> **
>   
>> Cheers,
>> Daniel
>>
>> On 03/06/06 04:02, Dr. Rodney G. McDuff wrote:
>>     
>>> I am try to get Windows Messenger v5.1 to play nicely with other UAs and
>>> SER/OpenSER and Asterisk. One of the problems that is confounding me is
>>> WM5 non-standard contact header which is of the form:
>>>
>>>     Contact:
>>> <sip:user at domain.net:5060;maddr=xxx.xxx.152.57;transport=tcp>;proxy=replace.
>>>
>>>
>>> The SIP RFC say that a maddr URL tag overrides the host part of the url
>>> (at least for the Via header). However when a UA uses this contact to
>>> send an ACK or BYE back to the WM5 UA , OpenSER does seem to be able to
>>> route it to xxx.xxx.152.57. If fact Openser pops the route header off
>>> (which contains the IP for the proxy) into the RURI and the response
>>> goes nowhere. (See attached trace)
>>> When I rewrite the contact in the config file but put the following code
>>> in route[0]:
>>>
>>>  
>>>       
>
>