NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
Hi, a common solution for UA's behind NAT is using
"fix_nated_contact()" to replace the private address with the received
address, so in-dialog request would be properly routed.
But this breaks the "Contact" the UA set in the REGISTER. This is:

- The UA registers with "Contact: <sip:user@PRIVATE_ADDRESS>".
- But later it receives in-dialog requests to RURI "sip:user@PUBLIC_ADDRESS".

AFAIK, a UA could refuse that in-dialog request because it has a RURI
different than the UA registered URI.

So I wonder, wouldn't be more ellegant to add a "Contact" parameter
"received" with the public address, and when the proxy receives an
in-dialog request then set the destination uri with that parameter
value? This is:

--------------------------------------------------------------------------
  alice (NAT)            Proxy                 bob
      <F1> INVITE  --->
                                 <F2> INVITE  --->
                                  <-----  <F3> BYE
       <-----  <F4> BYE


<F1>
INVITE sip:[hidden email] SIP/2.0
Contact: <sip:alice@PRIVATE_ADDRESS>

<F2>
INVITE sip:bob@BOB_IP SIP/2.0
Contact: <sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS">

<F3>
BYE sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS" SIP/2.0

--------
Now the Proxy sets the destination URI $du with "sip:PUBLIC_ADDRESS"
so the BYE is forwarded tu alice public address without changing the
RURI.
--------

<F4>
BYE sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS" SIP/2.0
--------------------------------------------------------------------------



This could be done manually in the script or with a new function (that
I suggest) in nathelper module, something as:

if nat_uac_test("19") {
    if ! is_method("REGISTER") {
       add_contact_received();
    }
}

Opcionally, this parameter could be inspected automatically during
t_relay to set the destination uri (not sure about it), or it could be
done in the script by checking manually a parameter "received" in the
Contact URI (note that this is not a parameter in the Contact heade,
but in the Contact URI:

    Contact: <sip:user@IP;received=x.x.x.x>     !=     Contact:
<sip:user@IP>;received=x.x.x.x

The parameter must appear in the Contact URI since it must appear in
the RURI of the in-dialog request.

Opinions?




--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
2008/11/7 Iñaki Baz Castillo <[hidden email]>:
> <F3>
> BYE sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS" SIP/2.0
>
> --------
> Now the Proxy sets the destination URI $du with "sip:PUBLIC_ADDRESS"
> so the BYE is forwarded tu alice public address without changing the
> RURI.
> --------

Is it possible to add a parameter in the Contact URI? I don't find an
elegant way.

--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the receivedpublic IP:port instead of adding a parameter with it?

Schumann Sebastian
Hi Inaki

I have to change the IP in the contact field, using avps and textops functions.

$avp(s:contact) = $ct;
avp_subst("$avp(s:contact)", "/(.*)@.*(>.*)/\1@10.0.0.1:5060\2/");
remove_hf("Contact");
append_hf("Contact: $avp(s:contact)\r\n");

Similarly, the regexp could check for the point to include your parameter and put it there.

Not so elegant though, but works fine for me.

Best regards
Sebastian

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Iñaki
> Baz Castillo
> Sent: Friday, 07. November 2008 13:59
> To: [hidden email]
> Subject: Re: [OpenSIPS-Users] NAT: Why replacing "Contact"
> with the receivedpublic IP:port instead of adding a parameter with it?
>
> 2008/11/7 Iñaki Baz Castillo <[hidden email]>:
> > <F3>
> > BYE sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS" SIP/2.0
> >
> > --------
> > Now the Proxy sets the destination URI $du with "sip:PUBLIC_ADDRESS"
> > so the BYE is forwarded tu alice public address without
> changing the
> > RURI.
> > --------
>
> Is it possible to add a parameter in the Contact URI? I don't
> find an elegant way.
>
> --
> Iñaki Baz Castillo
> <[hidden email]>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Klaus Darilion
In reply to this post by Iñaki Baz Castillo
Hi Inaki!

Funny - I am thinking of this since long time and had exactly the same
idea yesterday, except that:
  - I would name the function add_received_to_contact()
  - I thought of searching for "received" not in t_relay but during
loose_route() (by design the received param can only be in loose-routed
messages and this allows overriding $du manuall)
  - remove the receive param from RURI before forwarding (although it is
allowed by RFC 3261, maybe make this optional)

unfortunately I did not had time yet to implement it

regards
klaus

Iñaki Baz Castillo schrieb:

> Hi, a common solution for UA's behind NAT is using
> "fix_nated_contact()" to replace the private address with the received
> address, so in-dialog request would be properly routed.
> But this breaks the "Contact" the UA set in the REGISTER. This is:
>
> - The UA registers with "Contact: <sip:user@PRIVATE_ADDRESS>".
> - But later it receives in-dialog requests to RURI "sip:user@PUBLIC_ADDRESS".
>
> AFAIK, a UA could refuse that in-dialog request because it has a RURI
> different than the UA registered URI.
>
> So I wonder, wouldn't be more ellegant to add a "Contact" parameter
> "received" with the public address, and when the proxy receives an
> in-dialog request then set the destination uri with that parameter
> value? This is:
>
> --------------------------------------------------------------------------
>   alice (NAT)            Proxy                 bob
>       <F1> INVITE  --->
>                                  <F2> INVITE  --->
>                                   <-----  <F3> BYE
>        <-----  <F4> BYE
>
>
> <F1>
> INVITE sip:[hidden email] SIP/2.0
> Contact: <sip:alice@PRIVATE_ADDRESS>
>
> <F2>
> INVITE sip:bob@BOB_IP SIP/2.0
> Contact: <sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS">
>
> <F3>
> BYE sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS" SIP/2.0
>
> --------
> Now the Proxy sets the destination URI $du with "sip:PUBLIC_ADDRESS"
> so the BYE is forwarded tu alice public address without changing the
> RURI.
> --------
>
> <F4>
> BYE sip:alice@PRIVATE_ADDRESS;received="sip:PUBLIC_ADDRESS" SIP/2.0
> --------------------------------------------------------------------------
>
>
>
> This could be done manually in the script or with a new function (that
> I suggest) in nathelper module, something as:
>
> if nat_uac_test("19") {
>     if ! is_method("REGISTER") {
>        add_contact_received();
>     }
> }
>
> Opcionally, this parameter could be inspected automatically during
> t_relay to set the destination uri (not sure about it), or it could be
> done in the script by checking manually a parameter "received" in the
> Contact URI (note that this is not a parameter in the Contact heade,
> but in the Contact URI:
>
>     Contact: <sip:user@IP;received=x.x.x.x>     !=     Contact:
> <sip:user@IP>;received=x.x.x.x
>
> The parameter must appear in the Contact URI since it must appear in
> the RURI of the in-dialog request.
>
> Opinions?
>
>
>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the receivedpublic IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
In reply to this post by Schumann Sebastian
2008/11/7 Schumann Sebastian <[hidden email]>:

> Hi Inaki
>
> I have to change the IP in the contact field, using avps and textops functions.
>
> $avp(s:contact) = $ct;
> avp_subst("$avp(s:contact)", "/(.*)@.*(>.*)/\1@10.0.0.1:5060\2/");
> remove_hf("Contact");
> append_hf("Contact: $avp(s:contact)\r\n");
>
> Similarly, the regexp could check for the point to include your parameter and put it there.
>
> Not so elegant though, but works fine for me.

Thanks, but I wonder if it works with valid Contact as follow:

Contact: sip:user@domain
Contact: <sip:user@domain>
Contact: "<<<HI@HI>>>" <sip:user@domain>

Also note that if Contact is:
  Contact: sip:user@domain
and you want to add a parameter to Contact URI (not Contact header)
then it must be converted to:
  Contact: <sip:user@domain;new_param=xxx>

If it would be:
  Contact: sip:user@domain;new_param=xxx
then that param is a HEADER param (not a URI param) and it wouldn't be
include in the RURI when generating an indialog request.

--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
In reply to this post by Klaus Darilion
2008/11/7 Klaus Darilion <[hidden email]>:
> Hi Inaki!
>
> Funny - I am thinking of this since long time and had exactly the same idea
> yesterday, except that:

>  - I would name the function add_received_to_contact()

yeah!


>  - I thought of searching for "received" not in t_relay but during
> loose_route() (by design the received param can only be in loose-routed
> messages and this allows overriding $du manuall)

True, loose_route() could set $du with that parameter when present.


>  - remove the receive param from RURI before forwarding (although it is
> allowed by RFC 3261, maybe make this optional)

Yes, good idea. If not, the UA will receive a RURI with a URI
parameter that it didn't include (maybe it could refuse it?).


Thanks a lot.


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Schumann Sebastian
In reply to this post by Iñaki Baz Castillo
Hi Inaki

Yes, you are right. Seems my changes work where they should (all same type of phones where modification has to take place, Contact header somehow "well-defined") but are not universal.

I will take your inputs to improve my used functions. Thanks!

Best regards
Sebastian

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Iñaki
> Baz Castillo
> Sent: Friday, 07. November 2008 14:19
> Cc: [hidden email]
> Subject: Re: [OpenSIPS-Users] NAT: Why replacing "Contact"
> with thereceivedpublic IP:port instead of adding a parameter with it?
>
> 2008/11/7 Schumann Sebastian <[hidden email]>:
> > Hi Inaki
> >
> > I have to change the IP in the contact field, using avps
> and textops functions.
> >
> > $avp(s:contact) = $ct;
> > avp_subst("$avp(s:contact)", "/(.*)@.*(>.*)/\1@10.0.0.1:5060\2/");
> > remove_hf("Contact");
> > append_hf("Contact: $avp(s:contact)\r\n");
> >
> > Similarly, the regexp could check for the point to include
> your parameter and put it there.
> >
> > Not so elegant though, but works fine for me.
>
> Thanks, but I wonder if it works with valid Contact as follow:
>
> Contact: sip:user@domain
> Contact: <sip:user@domain>
> Contact: "<<<HI@HI>>>" <sip:user@domain>
>
> Also note that if Contact is:
>   Contact: sip:user@domain
> and you want to add a parameter to Contact URI (not Contact
> header) then it must be converted to:
>   Contact: <sip:user@domain;new_param=xxx>
>
> If it would be:
>   Contact: sip:user@domain;new_param=xxx then that param is a
> HEADER param (not a URI param) and it wouldn't be include in
> the RURI when generating an indialog request.
>
> --
> Iñaki Baz Castillo
> <[hidden email]>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
2008/11/7 Schumann Sebastian <[hidden email]>:
> Hi Inaki
>
> Yes, you are right. Seems my changes work where they should (all same type of phones where modification has to take place, Contact header somehow "well-defined") but are not universal.
>
> I will take your inputs to improve my used functions. Thanks!

I suggest you to study the SIP URI BNF grammar in RFC 3261. It's really complex.

Regards.


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Klaus Darilion
In reply to this post by Iñaki Baz Castillo


Iñaki Baz Castillo schrieb:

> 2008/11/7 Klaus Darilion <[hidden email]>:
>> Hi Inaki!
>>
>> Funny - I am thinking of this since long time and had exactly the same idea
>> yesterday, except that:
>
>>  - I would name the function add_received_to_contact()
>
> yeah!
>
>
>>  - I thought of searching for "received" not in t_relay but during
>> loose_route() (by design the received param can only be in loose-routed
>> messages and this allows overriding $du manuall)
>
> True, loose_route() could set $du with that parameter when present.
>
>
>>  - remove the receive param from RURI before forwarding (although it is
>> allowed by RFC 3261, maybe make this optional)
>
> Yes, good idea. If not, the UA will receive a RURI with a URI
> parameter that it didn't include (maybe it could refuse it?).

That was also my fear. But I checked RFC 3261 and is says for URI
comparison that parameters which are present only in one URI should be
ignored, thus the client should accept the URI also with the received
parameter. But this can done configureable

klaus

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Bogdan-Andrei Iancu
In reply to this post by Iñaki Baz Castillo
Hi Iñaki,

If I'm not wrong, it's it the "maddr" param what you are looking for.
Without aiming a bias, I was also evaluating the option to store the
original contact and to restore it back.

Regards,
Bogdan

Iñaki Baz Castillo wrote:

> 2008/11/7 Schumann Sebastian <[hidden email]>:
>  
>> Hi Inaki
>>
>> Yes, you are right. Seems my changes work where they should (all same type of phones where modification has to take place, Contact header somehow "well-defined") but are not universal.
>>
>> I will take your inputs to improve my used functions. Thanks!
>>    
>
> I suggest you to study the SIP URI BNF grammar in RFC 3261. It's really complex.
>
> Regards.
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
2008/11/7 Bogdan-Andrei Iancu <[hidden email]>:
> Hi Iñaki,
>
> If I'm not wrong, it's it the "maddr" param what you are looking for.
> Without aiming a bias, I was also evaluating the option to store the
> original contact and to restore it back.

Thanks, and how to add "maddr" to the Contact header?

--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
In reply to this post by Klaus Darilion
2008/11/7 Klaus Darilion <[hidden email]>:

>> Yes, good idea. If not, the UA will receive a RURI with a URI
>> parameter that it didn't include (maybe it could refuse it?).
>
> That was also my fear. But I checked RFC 3261 and is says for URI comparison
> that parameters which are present only in one URI should be ignored, thus
> the client should accept the URI also with the received parameter. But this
> can done configureable

You are right.


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Bogdan-Andrei Iancu
Why this problem - your proxy adds received at the contact and when the
contact (as ruri) goes back you strip it down...

Regards,
Bogdan

Iñaki Baz Castillo wrote:

> 2008/11/7 Klaus Darilion <[hidden email]>:
>
>  
>>> Yes, good idea. If not, the UA will receive a RURI with a URI
>>> parameter that it didn't include (maybe it could refuse it?).
>>>      
>> That was also my fear. But I checked RFC 3261 and is says for URI comparison
>> that parameters which are present only in one URI should be ignored, thus
>> the client should accept the URI also with the received parameter. But this
>> can done configureable
>>    
>
> You are right.
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Bogdan-Andrei Iancu
In reply to this post by Iñaki Baz Castillo
Do not get me wrong - was an indication  about what param should be used
- I was not saying about a usage way :).

But even now, with textops function you could add the maddr to contact
and use it from RURI - but a better approach will be to have some more
efficient script functions for this purpose.

Regards,
Bogdan

Iñaki Baz Castillo wrote:

> 2008/11/7 Bogdan-Andrei Iancu <[hidden email]>:
>  
>> Hi Iñaki,
>>
>> If I'm not wrong, it's it the "maddr" param what you are looking for.
>> Without aiming a bias, I was also evaluating the option to store the
>> original contact and to restore it back.
>>    
>
> Thanks, and how to add "maddr" to the Contact header?
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with the received public IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
In reply to this post by Bogdan-Andrei Iancu
2008/11/7 Bogdan-Andrei Iancu <[hidden email]>:
> Why this problem - your proxy adds received at the contact and when the
> contact (as ruri) goes back you strip it down...

Yes, the issue is adding that "received" to the Contact *URI* properly.  .)

--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Klaus Darilion
In reply to this post by Bogdan-Andrei Iancu


Bogdan-Andrei Iancu schrieb:
> Hi Iñaki,
>
> If I'm not wrong, it's it the "maddr" param what you are looking for.
> Without aiming a bias, I was also evaluating the option to store the
> original contact and to restore it back.

Technically, I think maddr can be used (and there is some vendor
equipment which uses it) and is probably the easiest way to implement
this feature.

But I think from the semantic point of view using maddr (=multicast
address) is misleading, as it is defined for usage of SIP with multicast.

regards
klaus

>
> Regards,
> Bogdan
>
> Iñaki Baz Castillo wrote:
>> 2008/11/7 Schumann Sebastian <[hidden email]>:
>>  
>>> Hi Inaki
>>>
>>> Yes, you are right. Seems my changes work where they should (all same type of phones where modification has to take place, Contact header somehow "well-defined") but are not universal.
>>>
>>> I will take your inputs to improve my used functions. Thanks!
>>>    
>> I suggest you to study the SIP URI BNF grammar in RFC 3261. It's really complex.
>>
>> Regards.
>>
>>
>>  
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
El Miércoles, 12 de Noviembre de 2008, Klaus Darilion escribió:
> But I think from the semantic point of view using maddr (=multicast
> address) is misleading, as it is defined for usage of SIP with multicast.

I agree. I would prefer a custom parameter ("received"?)

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Bogdan-Andrei Iancu
In reply to this post by Klaus Darilion
Hi Klaus,

It might be right (from semantic pov) - I suggested this as there are
other devices using it for similar purpose, so there is a kind of
unwritten convention and the probability to work (to be properly
interpreted by other devices) is higher.

BTW, did you know if the RFC recommends/specifies a param for this purpose ?

Regards,
Bogdan


Klaus Darilion wrote:

>
>
> Bogdan-Andrei Iancu schrieb:
>> Hi Iñaki,
>>
>> If I'm not wrong, it's it the "maddr" param what you are looking for.
>> Without aiming a bias, I was also evaluating the option to store the
>> original contact and to restore it back.
>
> Technically, I think maddr can be used (and there is some vendor
> equipment which uses it) and is probably the easiest way to implement
> this feature.
>
> But I think from the semantic point of view using maddr (=multicast
> address) is misleading, as it is defined for usage of SIP with multicast.
>
> regards
> klaus
>
>>
>> Regards,
>> Bogdan
>>
>> Iñaki Baz Castillo wrote:
>>> 2008/11/7 Schumann Sebastian <[hidden email]>:
>>>  
>>>> Hi Inaki
>>>>
>>>> Yes, you are right. Seems my changes work where they should (all
>>>> same type of phones where modification has to take place, Contact
>>>> header somehow "well-defined") but are not universal.
>>>>
>>>> I will take your inputs to improve my used functions. Thanks!
>>>>    
>>> I suggest you to study the SIP URI BNF grammar in RFC 3261. It's
>>> really complex.
>>>
>>> Regards.
>>>
>>>
>>>  
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: NAT: Why replacing "Contact" with thereceivedpublic IP:port instead of adding a parameter with it?

Iñaki Baz Castillo
El Jueves, 13 de Noviembre de 2008, Bogdan-Andrei Iancu escribió:
> It might be right (from semantic pov) - I suggested this as there are
> other devices using it for similar purpose, so there is a kind of
> unwritten convention and the probability to work (to be properly
> interpreted by other devices) is higher.
>
> BTW, did you know if the RFC recommends/specifies a param for this purpose
> ?

AFAIK there is no such specification.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users