B2BUA not passing ACKs

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

Re: B2BUA help

opensipslist

Hello Anca,

I'm approaching the problem from a different perspective now,
and making progress with your help. Please note the 'CSEQ'...

  Caller                 OpenSIPS B2B          Mediaserver
    |                         |                     |
  INVITE CSEQ 1 ------------->| INVITE CSEQ 2 ----->|
    |                         |                     |
    |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
    |                         |                     |
  INVITE CSEQ 2 ------------->| INVITE CSEQ 2 ----->|
    |                         |        !!!!!!       |
    |                         |                     |
    |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
    |                         |                     |

As you can see, the above scenario will not work. The B2B logic is
not increasing the CSEQ of the second incoming INVITE. This is the
real one that should actually start the dialog.

How do you recommend to correct this. Can I simply adjust your
prepaid.xml file?

My best guess is that I can insert a 'delete_entity' to try to
indicate to the B2b logic that a new dialog begins at the second
INVITE, but I don't know how to do that. Is this right?

  <!-- prepaid.xml, insert a new 'request' block  -->
  <rules>
      <request>
          <invite>
              <rule id="1">
                  <condition>
                      <state>1</state>
                      <sender>
                          <type>server</type>
                          <id>server1</id>
                      </sender>
                  </condition>

                  <action>
                      <delete_entity/>
                      <bridge>
                          <client>
                              <id>server1</id>
                          </client>
                          <client>
                              <id>client1</id>
                              <destination>
                                  <value type="initial">server1</value>
                              </destination>
                          </client>
                      </bridge>
                      <state>2</state>
                  </action>
              </rule>

Alternatively I could try changing the routing script to only call
the B2B logic at the second INVITE, but that would be very hacky.

    # initial requests
    if (is_method("INVITE") && src_ip != myself) {  # rewrite block
        if (!t_newtran()) {                         # to ignore any
            sl_reply_error();                       # INVITE request
            exit;                                   # without a Auth
        }                                           # header
        b2b_init_request("prepaid", "sip:[hidden email]:5080;transport=tcp", "sip:[hidden email]:5080;transport=tcp");
        exit;
    }

I prefer doing it correctly, by adjusting your prepaid.xml scenario.

Regards,
Brian

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

Re: B2BUA help

Anca Vamanu-2
Hi Brian,

I have thought about this problem and discussed with Bogdan and he come
up with the simplest solution - take the Cseq from the received Invite.
And your scenario should be solved.
I will make this change and let you know when to update from svn.

Regards,

--
Anca Vamanu
www.voice-system.ro



[hidden email] wrote:

> Hello Anca,
>
> I'm approaching the problem from a different perspective now,
> and making progress with your help. Please note the 'CSEQ'...
>
>   Caller                 OpenSIPS B2B          Mediaserver
>     |                         |                     |
>   INVITE CSEQ 1 ------------->| INVITE CSEQ 2 ----->|
>     |                         |                     |
>     |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
>     |                         |                     |
>   INVITE CSEQ 2 ------------->| INVITE CSEQ 2 ----->|
>     |                         |        !!!!!!       |
>     |                         |                     |
>     |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
>     |                         |                     |
>
> As you can see, the above scenario will not work. The B2B logic is
> not increasing the CSEQ of the second incoming INVITE. This is the
> real one that should actually start the dialog.
>
> How do you recommend to correct this. Can I simply adjust your
> prepaid.xml file?
>
> My best guess is that I can insert a 'delete_entity' to try to
> indicate to the B2b logic that a new dialog begins at the second
> INVITE, but I don't know how to do that. Is this right?
>
>   <!-- prepaid.xml, insert a new 'request' block  -->
>   <rules>
>       <request>
>           <invite>
>               <rule id="1">
>                   <condition>
>                       <state>1</state>
>                       <sender>
>                           <type>server</type>
>                           <id>server1</id>
>                       </sender>
>                   </condition>
>
>                   <action>
>                       <delete_entity/>
>                       <bridge>
>                           <client>
>                               <id>server1</id>
>                           </client>
>                           <client>
>                               <id>client1</id>
>                               <destination>
>                                   <value type="initial">server1</value>
>                               </destination>
>                           </client>
>                       </bridge>
>                       <state>2</state>
>                   </action>
>               </rule>
>
> Alternatively I could try changing the routing script to only call
> the B2B logic at the second INVITE, but that would be very hacky.
>
>     # initial requests
>     if (is_method("INVITE") && src_ip != myself) {  # rewrite block
>         if (!t_newtran()) {                         # to ignore any
>             sl_reply_error();                       # INVITE request
>             exit;                                   # without a Auth
>         }                                           # header
>         b2b_init_request("prepaid", "sip:[hidden email]:5080;transport=tcp", "sip:[hidden email]:5080;transport=tcp");
>         exit;
>     }
>
> I prefer doing it correctly, by adjusting your prepaid.xml scenario.
>
> Regards,
> Brian
>
> _______________________________________________
> 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: B2BUA help

opensipslist

Hello Anca,

An jeu., févr 11, 2010, Anca Vamanu schrieb:

>[hidden email] wrote:
>> I'm approaching the problem from a different perspective now,
>> and making progress with your help. Please note the 'CSEQ'...
>>
>>   Caller                 OpenSIPS B2B          Mediaserver
>>     |                         |                     |
>>   INVITE CSEQ 1 ------------->| INVITE CSEQ 2 ----->|
>>     |                         |                     |
>>     |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
>>     |                         |                     |
>>   INVITE CSEQ 2 ------------->| INVITE CSEQ 2 ----->|
>>     |                         |        !!!!!!       |
>>     |                         |                     |
>>     |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
>>     |                         |                     |
>>
>> As you can see, the above scenario will not work. The B2B logic
>> is not increasing the CSEQ of the second incoming INVITE. This
>> is the real one that should actually start the dialog.
>>
>I have thought about this problem and discussed with Bogdan and
>he come up with the simplest solution - take the Cseq from the
>received Invite. And your scenario should be solved. I will
>make this change and let you know when to update from svn.
>
That's good news. After trying a lot of things nothing worked.
I'll be patient for your updtate to come in and then integrate
the new code from SVN and test it. Thanks.

Regards,
Brian

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

Re: B2BUA help

Anca Vamanu-2
Hi Brian,

I have just committed the fix for this. Please update and test.

Regards,

--
Anca Vamanu
www.voice-system.ro




[hidden email] wrote:

> Hello Anca,
>
> An jeu., févr 11, 2010, Anca Vamanu schrieb:
>  
>> [hidden email] wrote:
>>    
>>> I'm approaching the problem from a different perspective now,
>>> and making progress with your help. Please note the 'CSEQ'...
>>>
>>>   Caller                 OpenSIPS B2B          Mediaserver
>>>     |                         |                     |
>>>   INVITE CSEQ 1 ------------->| INVITE CSEQ 2 ----->|
>>>     |                         |                     |
>>>     |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
>>>     |                         |                     |
>>>   INVITE CSEQ 2 ------------->| INVITE CSEQ 2 ----->|
>>>     |                         |        !!!!!!       |
>>>     |                         |                     |
>>>     |<-- 401 WWW-Authenticate |<-------- 401 WWW-Authenticate
>>>     |                         |                     |
>>>
>>> As you can see, the above scenario will not work. The B2B logic
>>> is not increasing the CSEQ of the second incoming INVITE. This
>>> is the real one that should actually start the dialog.
>>>
>>>      
>> I have thought about this problem and discussed with Bogdan and
>> he come up with the simplest solution - take the Cseq from the
>> received Invite. And your scenario should be solved. I will
>> make this change and let you know when to update from svn.
>>
>>    
> That's good news. After trying a lot of things nothing worked.
> I'll be patient for your updtate to come in and then integrate
> the new code from SVN and test it. Thanks.
>
> Regards,
> Brian
>
> _______________________________________________
> 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: B2BUA help

opensipslist

Hello Anca,

An jeu., févr 11, 2010, Anca Vamanu schrieb:
>I have just committed the fix for this. Please update and test.
>
I see that you made the changes in SVN revision 6596, however
when I build OpenSIPS 1.6.0 (after copying the entire b2b_entity
and b2b_logic modules from SVN 6596) the same problem is there.

At runtime, my UAC sends INVITE CSEQ 1 to OpenSIPS. The b2b_init
prepaid scenario then reads the message and makes a new one that
it forwards to parameter 1 of the XML script. Unfortunately, the
INVITE arriving at the media server has a CSEQ of 2 so I assume
that there is some defect with your changes in SVN 6596.

By the way, I'm not processing the INVITE in the route script
before b2b_init() begins. What do you think could be the problem?

Regards,
Brian

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

Re: B2BUA help

Anca Vamanu-2
Hi Brian,

[hidden email] wrote:

> Hello Anca,
>
> An jeu., févr 11, 2010, Anca Vamanu schrieb:
>  
>> I have just committed the fix for this. Please update and test.
>>
>>    
> I see that you made the changes in SVN revision 6596, however
> when I build OpenSIPS 1.6.0 (after copying the entire b2b_entity
> and b2b_logic modules from SVN 6596) the same problem is there.
>
> At runtime, my UAC sends INVITE CSEQ 1 to OpenSIPS. The b2b_init
> prepaid scenario then reads the message and makes a new one that
> it forwards to parameter 1 of the XML script. Unfortunately, the
> INVITE arriving at the media server has a CSEQ of 2 so I assume
> that there is some defect with your changes in SVN 6596.
>  
It is ok to have cseq 2 on the other side if the received Invite has
cseq 1. The implementation uses cseq +1 on the other side :). It should
not be an issue.
Only if for the authorized Invite the cseq is not 3 .. You observed this?

Regards,

--
Anca Vamanu
www.voice-system.ro


> By the way, I'm not processing the INVITE in the route script
> before b2b_init() begins. What do you think could be the problem?
>
> Regards,
> Brian
>
> _______________________________________________
> 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: B2BUA help

opensipslist

Hello Anca,

An ven., févr 12, 2010, Anca Vamanu schrieb:

>[hidden email] wrote:
>> An jeu., févr 11, 2010, Anca Vamanu schrieb:
>>> I have just committed the fix for this. Please update and test.
>>>
>> At runtime, my UAC sends INVITE CSEQ 1 to OpenSIPS. [...]
>> Unfortunately, the INVITE arriving at the media server has a
>> CSEQ of 2 so I assume that there is some defect with your
>> changes in SVN 6596.
>>
>It is ok to have cseq 2 on the other side if the received Invite
>has cseq 1. The implementation uses cseq +1 on the other side :).
>It should not be an issue.
>
You're right.

>Only if for the authorized Invite the cseq is not 3... You
>observed this?
>
My observation was wrong, and now it is clear that the B2B logic
is reading INVITE CSEQ 1 and rewriting to INVITE CSEQ 2. When it
retransmits the INVITE a second time with the 'Authorization'
header it does indeed increment the new INVITE CSEQ to 3 which
is correct. Thanks.

But it's still not working...

Problem

The UAC receives the 401 response from the B2B logic and produces
the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
the original (not B2B rewritten) RURI to calculate the MD5 string.

The B2B logic then takes the new INVITE with the 'Authorization'
header and rewrites the RURI before forwarding it to the media
server. This rewriting procedure is the same for both the RURI
and 'To' URI. Both are set to the <destination> parameter of the
B2B XML file.

When the client entity (media server) gets the new INVITE message
it rejects it because the RURI has changed thus invalidating the
'Authorization' string. Do you understand?

Solution

My idea to solve this problem is when specifying a client
destination in the B2B XML file, a client entity will be created.
As before, the 'To' tag will be rewritten to match the <destination>
but the RURI should not be changed. When B2B forwards the INVITE
message to the media server it will be accepted because the
'Authorization' header will be correct.

Do you agree, and if so what is the best way to achieve this?
Maybe it's best to add this new logic as an option to the
<destination> tag? That way the default behaviour would be
to still rewrite the RURI as B2B was doing before.

Regards,
Brian

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

Re: B2BUA help

opensipslist

Hello Anca,

An ven., févr 12, 2010, [hidden email] schrieb:

>An ven., févr 12, 2010, Anca Vamanu schrieb:
>>It is ok to have cseq 2 on the other side if the received Invite
>>has cseq 1. The implementation uses cseq +1 on the other side :).
>>It should not be an issue.
>>
>You're right.
>
>>Only if for the authorized Invite the cseq is not 3... You
>>observed this?
>>
>[...]
>
>But it's still not working...
>
>Problem
>
>The UAC receives the 401 response from the B2B logic and produces
>the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
>the original (not B2B rewritten) RURI to calculate the MD5 string.
>
>The B2B logic then takes the new INVITE with the 'Authorization'
>header and rewrites the RURI before forwarding it to the media
>server. This rewriting procedure is the same for both the RURI
>and 'To' URI. Both are set to the <destination> parameter of the
>B2B XML file.
>
>When the client entity (media server) gets the new INVITE message
>it rejects it because the RURI has changed thus invalidating the
>'Authorization' string. Do you understand?
>
>Solution
>
>My idea to solve this problem is when specifying a client
>destination in the B2B XML file, a client entity will be created.
>As before, the 'To' tag will be rewritten to match the <destination>
>but the RURI should not be changed. When B2B forwards the INVITE
>message to the media server it will be accepted because the
>'Authorization' header will be correct.
>
>Do you agree, and if so what is the best way to achieve this?
>Maybe it's best to add this new logic as an option to the
><destination> tag? That way the default behaviour would be
>to still rewrite the RURI as B2B was doing before.
>
I've looked at the code and searched for the place where the 'To'
header and RURI are independently set. It seems that some dialog
creation function of the TM module is being used, but I don't see
how to set the 'To' and RURI independently.

Have you thought about the problem I mentioned and the possible
solutions to it? I'm still stuck without a functioning B2BUA,
because the B2B logic is changing the RURI from the original
message.

Regards,
Brian

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

Re: B2BUA help

Anca Vamanu-2
Hi Brian,

You are right, the if RURI is changed the auth response calculation will
get a different result at the media server.
As a solution, I will add a scenario parameter that tells B2B logic not
to change the RURI, but keep the original one.
However, I must warn you again that if you use the complete prepaid
scenario and the media server will request authorization when the caller
is connected the second time to it, then it will not work. Because to
connect the caller to the media server the second time, a reinvite is
sent to the caller and am initial Invite to the media server after the
caller's phone replies with 200 OK. There is no way to do authorization
here.

But you can use only the first part, connecting the user to the media
server only once at the beginning.

Regards,

--
Anca Vamanu
www.voice-system.ro




[hidden email] wrote:

> Hello Anca,
>
> An ven., févr 12, 2010, [hidden email] schrieb:
>  
>> An ven., févr 12, 2010, Anca Vamanu schrieb:
>>    
>>> It is ok to have cseq 2 on the other side if the received Invite
>>> has cseq 1. The implementation uses cseq +1 on the other side :).
>>> It should not be an issue.
>>>
>>>      
>> You're right.
>>
>>    
>>> Only if for the authorized Invite the cseq is not 3... You
>>> observed this?
>>>
>>>      
>> [...]
>>
>> But it's still not working...
>>
>> Problem
>>
>> The UAC receives the 401 response from the B2B logic and produces
>> the 'Authorization' string based on RFC 2617 3.2.1/3.2.2. It uses
>> the original (not B2B rewritten) RURI to calculate the MD5 string.
>>
>> The B2B logic then takes the new INVITE with the 'Authorization'
>> header and rewrites the RURI before forwarding it to the media
>> server. This rewriting procedure is the same for both the RURI
>> and 'To' URI. Both are set to the <destination> parameter of the
>> B2B XML file.
>>
>> When the client entity (media server) gets the new INVITE message
>> it rejects it because the RURI has changed thus invalidating the
>> 'Authorization' string. Do you understand?
>>
>> Solution
>>
>> My idea to solve this problem is when specifying a client
>> destination in the B2B XML file, a client entity will be created.
>> As before, the 'To' tag will be rewritten to match the <destination>
>> but the RURI should not be changed. When B2B forwards the INVITE
>> message to the media server it will be accepted because the
>> 'Authorization' header will be correct.
>>
>> Do you agree, and if so what is the best way to achieve this?
>> Maybe it's best to add this new logic as an option to the
>> <destination> tag? That way the default behaviour would be
>> to still rewrite the RURI as B2B was doing before.
>>
>>    
> I've looked at the code and searched for the place where the 'To'
> header and RURI are independently set. It seems that some dialog
> creation function of the TM module is being used, but I don't see
> how to set the 'To' and RURI independently.
>
> Have you thought about the problem I mentioned and the possible
> solutions to it? I'm still stuck without a functioning B2BUA,
> because the B2B logic is changing the RURI from the original
> message.
>
> Regards,
> Brian
>
> _______________________________________________
> 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: B2BUA help

opensipslist

Hello Anca,

An lun., févr 22, 2010, Anca Vamanu schrieb:
>You are right, the if RURI is changed the auth response calculation
>will get a different result at the media server.  As a solution, I
>will add a scenario parameter that tells B2B logic not to change
>the RURI, but keep the original one.
>
Thanks, that will help a lot. Let us know how this addition goes.

>However, I must warn you again that if you use the complete prepaid
>scenario and the media server will request authorization when the caller
>is connected the second time to it, then it will not work. Because to
>connect the caller to the media server the second time, a reinvite is
>sent to the caller and am initial Invite to the media server after the
>caller's phone replies with 200 OK. There is no way to do authorization
>here.
>
I do vaguely understand what you are saying here. My goal doesn't
require the last INVITE to the media server, only the first one
is needed. It's still possible that a re-INVITE is sent by B2B
which causes authorization problems for my client, but I'm not
certain about that yet.

Even in the worst case there is good value in being able to connect
even a single dialog to a media server while using authorization,
so your plan to add the scenario parameter is justified.

>But you can use only the first part, connecting the user to the media
>server only once at the beginning.
>
Hopefully that will work out. I'll test it once you're finished.

Regards,
Brian

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