Daniel-Constantin Mierla wrote:

On 6/1/10 9:07 PM, Alex Balashov wrote:

...

No, it'll store the fixed one, in the proper contact column, not the received column. I do this all the time, even though it's not the "proper" way.

should be the original one with the last version, afaik. There were issues with phones accepting calls which had a different uri than the address they set in contact of register.

So, the contact details were brocken in:

• contact - the address from header
• received - built from source ip and port
• socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and fix_nated_registrar().

I know. I always use fix_nated_register. I just wonder why save() saves the fixed contact in case of fix_nated_contact(), because usually we have the problem that changes to the message are only visible when the message is forwarded (lumps are applied)

regards Klaus

Am 01.06.2010 22:08, schrieb Daniel-Constantin Mierla:

On 6/1/10 10:02 PM, Klaus Darilion wrote:

...

Daniel-Constantin Mierla wrote:

...

On 6/1/10 9:07 PM, Alex Balashov wrote:

...

No, it'll store the fixed one, in the proper contact column, not the received column. I do this all the time, even though it's not the "proper" way.

should be the original one with the last version, afaik. There were issues with phones accepting calls which had a different uri than the address they set in contact of register.

So, the contact details were brocken in:

• contact - the address from header
• received - built from source ip and port
• socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and fix_nated_registrar().

I know. I always use fix_nated_register. I just wonder why save() saves the fixed contact in case of fix_nated_contact(), because usually we have the problem that changes to the message are only visible when the message is forwarded (lumps are applied)

but are you sure the fixed contact is saved? I quick look in the registrar code seems to take the contact from headers, which are pointing inside original message.

I just tested with kamailio 3.0 and you are right. Yesterday I tested with ser 0.9.? and fix_nated_contact() seemed to save the rewritten contact header - strange.

Thanks klaus

On 6/2/10 10:58 AM, Klaus Darilion wrote:

Am 02.06.2010 10:46, schrieb Klaus Darilion:

...

Am 01.06.2010 22:08, schrieb Daniel-Constantin Mierla:

...

On 6/1/10 10:02 PM, Klaus Darilion wrote:

...

Daniel-Constantin Mierla wrote:

...

On 6/1/10 9:07 PM, Alex Balashov wrote:

...

No, it'll store the fixed one, in the proper contact column, not the received column. I do this all the time, even though it's not the "proper" way.

should be the original one with the last version, afaik. There were issues with phones accepting calls which had a different uri than the address they set in contact of register.

So, the contact details were brocken in:

• contact - the address from header
• received - built from source ip and port
• socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and fix_nated_registrar().

I know. I always use fix_nated_register. I just wonder why save() saves the fixed contact in case of fix_nated_contact(), because usually we have the problem that changes to the message are only visible when the message is forwarded (lumps are applied)

but are you sure the fixed contact is saved? I quick look in the registrar code seems to take the contact from headers, which are pointing inside original message.

I just tested with kamailio 3.0 and you are right. Yesterday I tested with ser 0.9.? and fix_nated_contact() seemed to save the rewritten contact header - strange.

I have to correct myself - I made an error during the test. Kamailio 3.0 with fix_nated_contact() saves the fixed contact URI (see below).

I will do some tests and look at it later. I checked my devel server and when using fix_nated_registrar() (like in default config) it is the address from contact header...

Thanks, Daniel

regards Klaus

U 2010/06/02 10:54:44.731304 83.136.33.3:46772 -> 83.136.32.159:5060 REGISTER sip:labs.nic.at SIP/2.0 Via: SIP/2.0/UDP 10.10.0.51:46772;branch=z9hG4bK-d8754z-5232d81c6b5f615a-1---d8754z-;rport Max-Forwards: 70 Contact: sip:klaus.darilion@10.10.0.51:46772;rinstance=cdb12231d83fce68;transport=udp

To: sip:klaus.darilion@labs.nic.at From: sip:klaus.darilion@labs.nic.at;tag=59004f11 Call-ID: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3ODllMmMzZTM. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Length: 0

U 2010/06/02 10:54:44.731304 83.136.32.159:5060 -> 83.136.33.3:46772 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.0.51:46772;branch=z9hG4bK-d8754z-5232d81c6b5f615a-1---d8754z-;rport=46772;received=83.136.33.3

To: sip:klaus.darilion@labs.nic.at;tag=5fcf32020f171aefa0445747f7988cba.e233

From: sip:klaus.darilion@labs.nic.at;tag=59004f11 Call-ID: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3ODllMmMzZTM. CSeq: 2 REGISTER Contact: sip:klaus.darilion@83.136.33.3:46772;rinstance=cdb12231d83fce68;expires=60

Server: kamailio (3.0.1 (i386/linux)) Content-Length: 0

# kamctl ul show Domain:: location table=512 records=1 max_slot=1 Contact:: sip:klaus.darilion@83.136.33.3:46772;rinstance=cdb12231d83fce68 Q= Expires:: 54 Callid:: NzE5Yjg0YTllNTFkNGIyZDA1N2NlY2I3OD Cseq:: 2 User-agent:: eyeBeam release 1102q stamp 51814 State:: CS_SYNC Flags:: 0 Cflag:: 64 Socket:: udp:83.136.32.159:5060 Methods:: 5087

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 6/2/10 3:00 PM, Andrei Pelinescu-Onciul wrote:

[...]

...

...

...

...

...

On 6/1/10 9:07 PM, Alex Balashov wrote:

> No, it'll store the fixed one, in the proper contact column, not the > received column. I do this all the time, even though it's not the > "proper" way. > should be the original one with the last version, afaik. There were issues with phones accepting calls which had a different uri than the address they set in contact of register.

So, the contact details were brocken in:

• contact - the address from header
• received - built from source ip and port
• socket - local socket where the register was received

Note that there are two functions, fix_nated_contact() and fix_nated_registrar().

I know. I always use fix_nated_register. I just wonder why save() saves the fixed contact in case of fix_nated_contact(), because usually we have the problem that changes to the message are only visible when the message is forwarded (lumps are applied)

but are you sure the fixed contact is saved? I quick look in the registrar code seems to take the contact from headers, which are pointing inside original message.

I just tested with kamailio 3.0 and you are right. Yesterday I tested with ser 0.9.? and fix_nated_contact() seemed to save the rewritten contact header - strange.

I have to correct myself - I made an error during the test. Kamailio 3.0 with fix_nated_contact() saves the fixed contact URI (see below).

In all versions (older ser, ser, sip-router, kamailio), the changes done by fix_nated_contact() will be visible when the contact is save()'d. fix_nated_contact() directly modifies the parsed contact, which is then used by save().

fix_nated_register() behaves differently. In older ser version and in kamailio it sets and avp with the received information. This avp is then checked by save() and used as received info. In newer ser versions and sip-router modules_s/nathelper it adds a received=... parameter to each contact (it doesn't set any avp). In this case save() will generate itself the received uri if the message is flagged as coming from before a NAT. save() from modules_s/registrar and newer sers, doesn't need fix_nated_register(), it only needs that the message was properly flagged in the script. It will also not look at any avp. ser's fix_nated_register() is used for replicated REGISTERs or when the outbound proxy is not also the registrar. It will add a "received=" parameter to each contact and the non-local registrar (or the replication peer) can use it to recover the original ip:port.

Interesting, thanks for these details. I never used fix_nated_contact() for REGISTER as fix_nated_registrar() is the natural way for me. You saved me some time to dig in the sources.

To understand that fix_nated_contact() translates the pointers to the new lump? If yes, that means the PVs for contact go there as well.

Cheers, Daniel

On 6/2/10 4:01 PM, Andrei Pelinescu-Onciul wrote:

On Jun 02, 2010 at 15:35, Daniel-Constantin Mierlamiconda@gmail.com wrote:

...

On 6/2/10 3:00 PM, Andrei Pelinescu-Onciul wrote:

...

[...]

...

...

...

>> On 6/1/10 9:07 PM, Alex Balashov wrote: >> >>> No, it'll store the fixed one, in the proper contact column, not the >>> received column. I do this all the time, even though it's not the >>> "proper" way. >>> >> should be the original one with the last version, afaik. There were >> issues with phones accepting calls which had a different uri than the >> address they set in contact of register. >> >> So, the contact details were brocken in: >> - contact - the address from header >> - received - built from source ip and port >> - socket - local socket where the register was received >> >> Note that there are two functions, fix_nated_contact() and >> fix_nated_registrar(). >> > I know. I always use fix_nated_register. I just wonder why save() > saves the fixed contact in case of fix_nated_contact(), because > usually we have the problem that changes to the message are only > visible when the message is forwarded (lumps are applied) > > but are you sure the fixed contact is saved? I quick look in the registrar code seems to take the contact from headers, which are pointing inside original message.

I just tested with kamailio 3.0 and you are right. Yesterday I tested with ser 0.9.? and fix_nated_contact() seemed to save the rewritten contact header - strange.

I have to correct myself - I made an error during the test. Kamailio 3.0 with fix_nated_contact() saves the fixed contact URI (see below).

In all versions (older ser, ser, sip-router, kamailio), the changes done by fix_nated_contact() will be visible when the contact is save()'d. fix_nated_contact() directly modifies the parsed contact, which is then used by save().

fix_nated_register() behaves differently. In older ser version and in kamailio it sets and avp with the received information. This avp is then checked by save() and used as received info. In newer ser versions and sip-router modules_s/nathelper it adds a received=... parameter to each contact (it doesn't set any avp). In this case save() will generate itself the received uri if the message is flagged as coming from before a NAT. save() from modules_s/registrar and newer sers, doesn't need fix_nated_register(), it only needs that the message was properly flagged in the script. It will also not look at any avp. ser's fix_nated_register() is used for replicated REGISTERs or when the outbound proxy is not also the registrar. It will add a "received=" parameter to each contact and the non-local registrar (or the replication peer) can use it to recover the original ip:port.

Interesting, thanks for these details. I never used fix_nated_contact() for REGISTER as fix_nated_registrar() is the natural way for me. You saved me some time to dig in the sources.

To understand that fix_nated_contact() translates the pointers to the new lump? If yes, that means the PVs for contact go there as well.

It does c->uri.s = buf, where buf is pkg_malloc'ed and contains the "fixed" uri (and it's used also in insert_new_lump_after()).

I wouldn't use fix_nated_contact() for REGISTERs, but sometimes it's useful to fix contacts in dialogs.

for dialogs is used indeed. Default K config has it to fix natted calls.

I think Juha added a new way lately, to encode/decode source ip/port in the contact uri.

Cheers, Daniel