According to rfc3261, REGISTER is a dialog.

My problem is: if this hostname resolves to more than one IP addresses, and the 401 comes from IP1, then the second REGISTER goes to IP2, then IP will continue to reject the message etc. Also, I am not completely sure but I think the same problem occurs in normal calls as well.

2009/9/24 Juha Heinanen jh@tutpro.com:

catalina oancea writes:

> It seems that kamailio does dns lookup again when receiving REGISTER  > 2, although both registers are part of the same dialog. Is this the  > expected behavior?

i don't think that register requests establish any dialogs.  when registrar receives the second register, it has complete forgotten about the first.

-- juha

24 sep 2009 kl. 12.04 skrev catalina oancea:

According to rfc3261, REGISTER is a dialog.

As I have been discussing this many times and you seem so sure, can you please point out where this is documented?

I've seen both kinds of implementations, some that assume that REGISTER/40x and the next REGISTER are within the same dialog and some that do not assume that.

Thank you!

/Olle

Hello,

On 24.09.2009 12:10 Uhr, catalina oancea wrote:

Hi,

In my scenario kamailio is not a registrar, it's just a proxy forwarding requests from asterisk to the provider.

I see.

As Juha said, REGISTER does not create a real dialog, since the contact in 200OK is the address of publisher not of destination. So a proxy does not have within-dialog like routing information.

So here is a hack you can try: - add record route on your proxy - the provider should add its own record route to REGISTER reply -- if it is kamailio, that is simple via append_to_reply() from textops, just before save() call. - hope/pray that asterisk is using these dialog info for building re-registration messages - on your kamailio route based on Route header

Cheers, Daniel

2009/9/24 Daniel-Constantin Mierla miconda@gmail.com:

...

Hello,

On 24.09.2009 11:47 Uhr, catalina oancea wrote:

...

Hi all,

I tested the following scenario:

astreisk kamailio provider(hostname) --------------------> dns lookup --------------------> REGISTER 1 REGISTER 1

    <--------------------                      <--------------------
     401                                          401

     -------------------->   dns lookup     -------------------->
     REGISTER 2                              REGISTER 2
     (same dialog, increased cseq)

It seems that kamailio does dns lookup again when receiving REGISTER 2, although both registers are part of the same dialog. Is this the expected behavior?

IIRC now, there is no place in registrar related modules (registrar and usrloc) where DNS query is done. You have some checks in your config that caused that.

There is also an option to fetch existing contacts from location and see if it is an update (matching by call id and cseq) and do directly save("location").

Cheers, Daniel

-- Daniel-Constantin Mierla

• Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
• http://www.asipto.com/index.php/sip-router-masterclass/

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

Hi again

I probably misunderstood the RFC. But an INVITE does create a dialog, and the situation:

asterisk kamailio provider(hostname) --------------------> dns lookup --------------------> INVITE 1 INVITE 1

<-------------------- <-------------------- 407 407

--------------------> dns lookup --------------------> INVITE 2 INVITE 2 (authenticated)

would have the same problem.

But the htable idea seems OK, I will try it.

Thanks everybody

2009/9/24 Klaus Darilion klaus.mailinglists@pernau.at:

Daniel-Constantin Mierla schrieb:

...

Hello,

On 24.09.2009 12:10 Uhr, catalina oancea wrote:

...

Hi,

In my scenario kamailio is not a registrar, it's just a proxy forwarding requests from asterisk to the provider.

I see.

As Juha said, REGISTER does not create a real dialog, since the contact in 200OK is the address of publisher not of destination. So a proxy does not have within-dialog like routing information.

So here is a hack you can try:

• add record route on your proxy
• the provider should add its own record route to REGISTER reply -- if it

is kamailio, that is simple via append_to_reply() from textops, just before save() call.

works only if the provider use Kamailio (in which case syncronized nonces shouldn't be a problem)

...

• hope/pray that asterisk is using these dialog info for building

re-registration messages

I don't think that will work.

klaus

...

• on your kamailio route based on Route header

Cheers, Daniel

...

2009/9/24 Daniel-Constantin Mierla miconda@gmail.com:

...

Hello,

On 24.09.2009 11:47 Uhr, catalina oancea wrote:

...

Hi all,

I tested the following scenario:

astreisk                        kamailio  provider(hostname)       -------------------->    dns lookup     -------------------->         REGISTER 1                              REGISTER 1

<--------------------                      <--------------------         401                                          401

-------------------->   dns lookup     -------------------->         REGISTER 2                              REGISTER 2         (same dialog, increased cseq)

It seems that kamailio does dns lookup again when receiving REGISTER 2, although both registers are part of the same dialog. Is this the expected behavior?

IIRC now, there is no place in registrar related modules (registrar and usrloc) where DNS query is done. You have some checks in your config that caused that.

There is also an option to fetch existing contacts from location and see if it is an update (matching by call id and cseq) and do directly save("location").

Cheers, Daniel

-- Daniel-Constantin Mierla

• Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
• http://www.asipto.com/index.php/sip-router-masterclass/

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

I understand your point, but let's say the dialog is created:

asterisk kamailio provider(hostname) --------------------> dns lookup --------------------> INVITE INVITE

<-------------------- <-------------------- 200Ok 200OK

Then the problem appears for each subsequent message(I tested with BYE):

--------------------> dns lookup --------------------> BYE BYE

2009/9/24 Juha Heinanen jh@tutpro.com:

catalina oancea writes:

> I probably misunderstood the RFC. But an INVITE does create a dialog,  > and the situation:  >  > asterisk                        kamailio                provider(hostname)  >          -------------------->    dns lookup     -------------------->  >          INVITE 1                                 INVITE 1  >  >         <--------------------                      <--------------------  >          407                                          407  >  >          -------------------->   dns lookup     -------------------->  >         INVITE 2                                 INVITE 2  >          (authenticated)

yes, invite does create a dialog, but that will not happen before invite 2 receives a reply that has tag in to header, i.e., invite 2 does not belong to a dialog.

-- juha

Hello,

On 24.09.2009 13:22 Uhr, catalina oancea wrote:

Hi again

I probably misunderstood the RFC.

I misunderstood your first email, I though is about registration refreshes (send updates to same server). Not the authentication case, because there is no dialog created in this situation, not even for INVITE. Dialog is created only after a 200ok (early dialogs after >100 < 200 replies).

htable is indeed an option.

Cheers, Daniel

But an INVITE does create a dialog, and the situation:

asterisk kamailio provider(hostname) --------------------> dns lookup --------------------> INVITE 1 INVITE 1

    <--------------------                      <--------------------
     407                                          407

     -------------------->   dns lookup     -------------------->
    INVITE 2                                 INVITE 2
     (authenticated)

would have the same problem.

But the htable idea seems OK, I will try it.

Thanks everybody

2009/9/24 Klaus Darilion klaus.mailinglists@pernau.at:

...

Daniel-Constantin Mierla schrieb:

...

Hello,

On 24.09.2009 12:10 Uhr, catalina oancea wrote:

...

Hi,

In my scenario kamailio is not a registrar, it's just a proxy forwarding requests from asterisk to the provider.

I see.

As Juha said, REGISTER does not create a real dialog, since the contact in 200OK is the address of publisher not of destination. So a proxy does not have within-dialog like routing information.

So here is a hack you can try:

• add record route on your proxy
• the provider should add its own record route to REGISTER reply -- if it

is kamailio, that is simple via append_to_reply() from textops, just before save() call.

works only if the provider use Kamailio (in which case syncronized nonces shouldn't be a problem)

...

• hope/pray that asterisk is using these dialog info for building

re-registration messages

I don't think that will work.

klaus

...

• on your kamailio route based on Route header

Cheers, Daniel

...

2009/9/24 Daniel-Constantin Mierla miconda@gmail.com:

...

Hello,

On 24.09.2009 11:47 Uhr, catalina oancea wrote:

...

Hi all,

I tested the following scenario:

astreisk kamailio provider(hostname) --------------------> dns lookup --------------------> REGISTER 1 REGISTER 1

   <--------------------                      <--------------------
    401                                          401

    -------------------->   dns lookup     -------------------->
    REGISTER 2                              REGISTER 2
    (same dialog, increased cseq)

It seems that kamailio does dns lookup again when receiving REGISTER 2, although both registers are part of the same dialog. Is this the expected behavior?

IIRC now, there is no place in registrar related modules (registrar and usrloc) where DNS query is done. You have some checks in your config that caused that.

There is also an option to fetch existing contacts from location and see if it is an update (matching by call id and cseq) and do directly save("location").

Cheers, Daniel

-- Daniel-Constantin Mierla

• Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
• http://www.asipto.com/index.php/sip-router-masterclass/

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

As I said earlier, I misunderstood some things. sorry for the trouble.

2009/9/25 Olle E. Johansson oej@edvina.net:

24 sep 2009 kl. 12.46 skrev Daniel-Constantin Mierla:

...

Hello,

On 24.09.2009 12:10 Uhr, catalina oancea wrote:

...

Hi,

In my scenario kamailio is not a registrar, it's just a proxy forwarding requests from asterisk to the provider.

I see.

As Juha said, REGISTER does not create a real dialog, since the contact in 200OK is the address of publisher not of destination. So a proxy does not have within-dialog like routing information.

So here is a hack you can try:

• add record route on your proxy
• the provider should add its own record route to REGISTER reply -- if it

is kamailio, that is simple via append_to_reply() from textops, just before save() call.

• hope/pray that asterisk is using these dialog info for building

re-registration messages

• on your kamailio route based on Route header

RFC 3261, section 10.3: Registrars MUST ignore the Record-Route header field if it is included in a REGISTER request. Registrars MUST NOT include a Record-Route header field in any response to a REGISTER request. A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record-Route header field value.

Oops.

/O

...

Cheers, Daniel

...

2009/9/24 Daniel-Constantin Mierla miconda@gmail.com:

...

Hello,

On 24.09.2009 11:47 Uhr, catalina oancea wrote:

...

Hi all,

I tested the following scenario:

astreisk                        kamailio  provider(hostname)      -------------------->    dns lookup     -------------------->        REGISTER 1                              REGISTER 1

<--------------------                      <--------------------        401                                          401

-------------------->   dns lookup     -------------------->        REGISTER 2                              REGISTER 2        (same dialog, increased cseq)

It seems that kamailio does dns lookup again when receiving REGISTER 2, although both registers are part of the same dialog. Is this the expected behavior?

IIRC now, there is no place in registrar related modules (registrar and usrloc) where DNS query is done. You have some checks in your config that caused that.

There is also an option to fetch existing contacts from location and see if it is an update (matching by call id and cseq) and do directly save("location").

Cheers, Daniel

-- Daniel-Constantin Mierla

• Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
• http://www.asipto.com/index.php/sip-router-masterclass/

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

-- Daniel-Constantin Mierla

• Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
• http://www.asipto.com/index.php/sip-router-masterclass/

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

---

• Olle E Johansson - oej@edvina.net
• Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

El Jueves, 24 de Septiembre de 2009, Daniel-Constantin Mierla escribió:

Hello,

On 24.09.2009 12:10 Uhr, catalina oancea wrote:

...

Hi,

In my scenario kamailio is not a registrar, it's just a proxy forwarding requests from asterisk to the provider.

I see.

As Juha said, REGISTER does not create a real dialog, since the contact in 200OK is the address of publisher not of destination. So a proxy does not have within-dialog like routing information.

So here is a hack you can try:

• add record route on your proxy

Record-Route in a REGISTER?? :)

• the provider should add its own record route to REGISTER reply -- if

it is kamailio, that is simple via append_to_reply() from textops, just before save() call.

This "hack" would work just in both, proxy and registrar, are Kamailio. But, if they are Kamailio then using PATH mechanism is the ellegant and official solution :)

As far as I understood, the original mail talks about Kamailio as proxy and Asterisk as registrar behind the proxy. Asterisk is not ready for that scenario.

Remember that Asterisk is designed to speak with dumb phones, to send calls to PSTN trunks and to play animal sounds by pressing DTMF's. But you can always code a PHP AGI to kill a database.

El Sábado, 26 de Septiembre de 2009, Daniel-Constantin Mierla escribió:

it was about possibility to consider "register" as dialog and try to route next registrations without doing dns.

Ok. Then she would do better by doing fixed routing of REGISTER requests (based on From for example). She could use LCR module to add failover (if the "primary" Asterisk-registrar is down, next REGISTER's are routed to the "secondary" one.

Regards.ç

El Sábado, 26 de Septiembre de 2009, Daniel-Constantin Mierla escribió:

On 26.09.2009 21:48 Uhr, Iñaki Baz Castillo wrote:

...

El Sábado, 26 de Septiembre de 2009, Daniel-Constantin Mierla escribió:

...

it was about possibility to consider "register" as dialog and try to route next registrations without doing dns.

Ok. Then she would do better by doing fixed routing of REGISTER requests (based on From for example). She could use LCR module to add failover (if the "primary" Asterisk-registrar is down, next REGISTER's are routed to the "secondary" one.

the problem was that the registrars are owned by someone else. The routing is done by DNS and the owner of registrars does dns load balancing, so returns different ip for DNS queries. So, using hash table to cache the relation user-ip came as proposal later in the discussion.

Really an exotic scenario... why to use registration based on DNS if the DNS is "dynamic" (DNS load balancing)?

I understand that she has various Asterisk and a Kamailio doing dispatching for registrations, but she wants that an already registered user is routed to the same Asterisk-registrar for refresh registrations. Using DNS load balancing is a bad solution (IMHO).

A better approach (IMHO too) would be using the dispatcher module (based on From) to route the REGISTER without using DNS load balancing. This is, all the clients sends a REGISTER with RURI "sip:mydomain.org", Kamailio receives them and routes to some Asterisk after performing dispatching based on From URI.

In this way, all the registers from the same user would be routed to the same Asterisk. And also, using dispatcher module (or LCR) we also get failover (in the current solution, if an Asterisk crashes but the DNS returns its address, then the registration would fail).

Regards.

2009/9/27 Olle E. Johansson oej@edvina.net:

...

As far as I understood, the original mail talks about Kamailio as proxy and Asterisk as registrar behind the proxy. Asterisk is not ready for that scenario.

Well, if Asterisk has proper support for outbound proxys compiled, it will work, but only with *one* proxy in front of Asterisk.

Yes, but AFAIR the registrar behind a proxy (Asterisk in this case) should add "Route: PROXY" for requests to registered users. Does Asterisk append it? (not sure now).