[OpenSIPS-Users] resending the ACK to itself
Toyima Dias
toyimads at gmail.com
Thu Feb 24 14:42:22 CET 2011
I'm going to reformulate my doubt here,
I have an Asterisk as a GW, i don't want to ask for authentication to
incoming calls (coming from the Asterisk), so i did the following:
Previously i added the IP of the Asterisk to the table "domain" so the
function is_from_local could check the from domain in the domain table and
get into the if statemen....
Now my doubt is why do i have to use check_source_addres after checking the
is_from_local? does it make any sence? Also, adding the IP of the GW to the
domain table will produce the mentioned bucle on the first message of this
thread...Am i doind sometrhing wrong?
if (!(method=="REGISTER") && is_from_local()) /*multidomain version*/
{
if(!check_source_address("0")){
if (!proxy_authorize("", "subscriber")) {
proxy_challenge("", "0");
exit;
}
if (!db_check_from()) {
sl_send_reply("403","Forbidden auth ID");
exit;
}
##
consume_credentials();
## # caller authenticated
}
}
.
.
.
.
.
if (!is_uri_host_local())
{
if(is_from_local()) {
route(1);
} else {
sl_send_reply("403","Not Here");
}
}
Any help would be appreciated!
Best Regards
2011/2/22 Toyima Dias <toyimads at gmail.com>
> Hi Tyler,
>
> 2011/2/22 Tyler Merritt <tyler at fonality.com>
>
> Check the subscribers table - this is where authentication happens. The
>> domain table (as I understand it) is only used to check what is a "local"
>> domain and what isn't - but this isn't what makes a registration transaction
>> occur.
>
>
> Registration? the problem is not related to registrations my friend.
>
>
>> check_source_address() compares the IP against the address table - not the
>> domain table. So that part of your code isn't even matching (unless you had
>> the IP of the Asterisk server in the address table as group 0).
>>
>>
>
> That's right, but the problem is that before checking "chec_source_addres"
> the line * if (!(method=="REGISTER") && is_from_local()) * filters the
> request because the *is_from_local* checks that the domain of the FROM
> header of the Asterisk invite is not in the domain table. If i put the
> address of the Asterisk in the domain table the ACK loop starts.
>
>
>> If you want Asterisk to authenticate - and you do not want incoming calls
>> to the proxy to authenticate, make sure the subscriber's FROM domain is NOT
>> in the domain table.
>>
>>
>
> I don't want to authenticate calls from the Asterisk, because Asterisk is a
> GW and is not necessary to authenticate incoming calls.
>
>
>> You could rip out the is_from_local() and replace it with
>> check_source_address() and then make sure the Asterisk server is on the
>> address table. It will accomplish the same thing in the end.
>>
>>
>
> Ok i will check it :)
>
>
>> Or you could just say (if $si==ASTERISK IP) { consume_credentials(); }
>> but that will register on every transaction type initially (including a
>> registration method which doesn't make sense because of course we're trying
>> to authenticate).
>>
>> This code forces a challenge for "outbound" calls from my point of view.
>>
>> The check_source_address() function is useful when you have multiple boxes
>> behind a single proxy, you don't want if ($si==A, || $si==B, etc.) in your
>> routing block - you can put all the IPs in the table and then just use the
>> one function to check against a group (in the case below - group 0)
>>
>> On Mon, Feb 21, 2011 at 11:29 PM, Toyima Dias <toyimads at gmail.com>wrote:
>>
>>> oops, sorry, i sent the message without finishing :S here i go again:
>>>
>>> I've found a "solution" for this problem, the problem was that i had
>>> the ip addres of the Asterisk server on the table "domain";
>>>
>>> I have this configuration on my script: (only the important section to be
>>> checked)
>>>
>>> if (!(method=="REGISTER") && is_from_local()) /*multidomain version*/
>>> {
>>> if(!check_source_address("0")){
>>> if (!proxy_authorize("", "subscriber")) {
>>> proxy_challenge("", "0");
>>> exit;
>>> }
>>> if (!db_check_from()) {
>>> sl_send_reply("403","Forbidden auth ID");
>>> exit;
>>> }
>>> consume_credentials();
>>> ## # caller authenticated
>>>
>>> }
>>> }
>>> # preloaded route checking
>>> if (loose_route()) {
>>> xlog("L_ERR",
>>> "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]");
>>> if (!is_method("ACK"))
>>> sl_send_reply("403","Preload Route denied");
>>> exit;
>>> }
>>>
>>> .
>>> .
>>> .
>>>
>>> if (!is_uri_host_local())
>>> {
>>> if(is_from_local()) {
>>> route(1);
>>> } else {
>>> sl_send_reply("403","Not Here");
>>> }
>>> }
>>>
>>> Now my doubt is about the permission section (address table), if i delete
>>> the ip address of my Asterisk from the address table the proxy will always
>>> process the request from it, so i do not understand the purpose of the line
>>> if(!check_source_address("0")) after if (!(method=="REGISTER") &&
>>> is_from_local()), as any request coming from the Asterisk will have a FROM
>>> different from the OpenSIPS domain...so that's why i entered the ip of the
>>> Asterisk on the domain table because the is_from_local checks the host part
>>> of the domain table
>>> Is there any explanation about this, am i missing something?
>>>
>>> Best Regards!
>>>
>>>
>>>
>>>
>>>
>>> 2011/2/21 Toyima Dias <toyimads at gmail.com>
>>>
>>> Hello,
>>>>
>>>> I've found a "solution" for this problem, the problem was that i had the
>>>> ip addres of the Asterisk server on the table "domain";
>>>> I have this configuratíon on my script:
>>>>
>>>> if (!(method=="REGISTER") && is_from_local()) /*multidomain version*/
>>>> {
>>>> if(!check_source_address("0")){
>>>> if (!proxy_authorize("", "subscriber")) {
>>>> proxy_challenge("", "0");
>>>> exit;
>>>> }
>>>> if (!db_check_from()) {
>>>> sl_send_reply("403","Forbidden auth ID");
>>>> exit;
>>>> }
>>>> ##
>>>> #xlog("L_WARN", "Thanks for the authorization - The call [$ru] will
>>>> continue to the destination - see ya ;) ; => 200 OK to NON REGISTER");
>>>> consume_credentials();
>>>> ## # caller authenticated
>>>> }
>>>> xlog("L_INFO","la IP SI esta dada de alta en el sistema");
>>>> }
>>>> xlog("L_INFO","no entra al bucle");
>>>> # preloaded route checking
>>>> if (loose_route()) {
>>>> xlog("L_ERR",
>>>> "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]");
>>>> if (!is_method("ACK"))
>>>> sl_send_reply("403","Preload Route denied");
>>>> exit;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2011/2/17 Toyima Dias <toyimads at gmail.com>
>>>>
>>>> Hello community,
>>>>>
>>>>> I'm having a weird error connecting my OpenSIPS with my Asterisk
>>>>> server, this is the scenario:
>>>>>
>>>>> A (172.30.140.18:55063) --> OpenSIPS (172.30.140.57:5060) --> Asterisk
>>>>> (172.30.140.40:5060) --> B
>>>>>
>>>>> and now take a look at the traces:
>>>>>
>>>>> U 2011/02/17 11:53:01.933871 172.30.140.18:55063 -> 172.30.140.57:5060
>>>>> INVITE sip:011887238976894563045 at 172.30.140.57 SIP/2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;branch=z9hG4bK-d87543-2f38213d4413f513-1--d87543-;rport^@
>>>>> Max-Forwards: 70^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57>^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 INVITE^@
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>> SUBSCRIBE, INFO^@
>>>>> Content-Type: application/sdp^@
>>>>> Proxy-Authorization: Digest
>>>>> username="1000",realm="172.30.140.57",nonce="4d5cfe2b0000000225b0486d17b27e44f8d7c14d191f0ae7",uri="
>>>>> sip:011887238976894563045 at 172.30.140.57
>>>>> ",response="6c7defa53d5c68c1f3d2b5fda8400be6",algorithm=MD5^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 372^@
>>>>> ^@
>>>>> v=0^@
>>>>> o=- 2 2 IN IP4 172.30.140.18^@
>>>>> s=CounterPath X-Lite 3.0^@
>>>>> c=IN IP4 172.30.140.18^@
>>>>> t=0 0^@
>>>>> m=audio 50020 RTP/AVP 107 119 100 106 0 105 98 8 101^@
>>>>> a=fmtp:101 0-15^@
>>>>> a=rtpmap:107 BV32/16000^@
>>>>> a=rtpmap:119 BV32-FEC/16000^@
>>>>> a=rtpmap:100 SPEEX/16000^@
>>>>> a=rtpmap:106 SPEEX-FEC/16000^@
>>>>> a=rtpmap:105 SPEEX-FEC/8000^@
>>>>> a=rtpmap:98 iLBC/8000^@
>>>>> a=rtpmap:101 telephone-event/8000^@
>>>>> a=sendrecv^@
>>>>>
>>>>>
>>>>> U 2011/02/17 11:53:01.935400 172.30.140.57:5060 -> 172.30.140.40:5060
>>>>> INVITE sip:887238976894563045 at 172.30.140.40 SIP/2.0^@
>>>>> Record-Route: <sip:172.30.140.57;lr=on>^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-2f38213d4413f513-1--d87543-;rport=55063^@
>>>>> Max-Forwards: 69^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57>^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 INVITE^@
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>> SUBSCRIBE, INFO^@
>>>>> Content-Type: application/sdp^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 372^@
>>>>> ^@
>>>>> v=0^@
>>>>> o=- 2 2 IN IP4 172.30.140.18^@
>>>>> s=CounterPath X-Lite 3.0^@
>>>>> c=IN IP4 172.30.140.18^@
>>>>> t=0 0^@
>>>>> m=audio 50020 RTP/AVP 107 119 100 106 0 105 98 8 101^@
>>>>> a=fmtp:101 0-15^@
>>>>> a=rtpmap:107 BV32/16000^@
>>>>> a=rtpmap:119 BV32-FEC/16000^@
>>>>> a=rtpmap:100 SPEEX/16000^@
>>>>> a=rtpmap:106 SPEEX-FEC/16000^@
>>>>> a=rtpmap:105 SPEEX-FEC/8000^@
>>>>> a=rtpmap:98 iLBC/8000^@
>>>>> a=rtpmap:101 telephone-event/8000^@
>>>>> a=sendrecv^@
>>>>>
>>>>>
>>>>> U 2011/02/17 11:53:02.284379 172.30.140.40:5060 -> 172.30.140.57:5060
>>>>> SIP/2.0 180 Ringing^@
>>>>> Via: SIP/2.0/UDP
>>>>> 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.0;received=172.30.140.57^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-2f38213d4413f513-1--d87543-;rport=55063^@
>>>>> Record-Route: <sip:172.30.140.57;lr=on>^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 INVITE^@
>>>>> User-Agent: Asterisk PBX^@
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY^@
>>>>> Supported: replaces^@
>>>>> Contact: <sip:887238976894563045 at 172.30.140.40>^@
>>>>> Content-Length: 0^@
>>>>> ^@
>>>>>
>>>>> #
>>>>> U 2011/02/17 11:53:02.284672 172.30.140.57:5060 -> 172.30.140.18:55063
>>>>> SIP/2.0 180 Ringing^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-2f38213d4413f513-1--d87543-;rport=55063^@
>>>>> Record-Route: <sip:172.30.140.57;lr=on>^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 INVITE^@
>>>>> User-Agent: Asterisk PBX^@
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY^@
>>>>> Supported: replaces^@
>>>>> Contact: <sip:887238976894563045 at 172.30.140.40>^@
>>>>> Content-Length: 0^@
>>>>> ^@
>>>>>
>>>>> U 2011/02/17 11:53:03.298391 172.30.140.40:5060 -> 172.30.140.57:5060
>>>>> SIP/2.0 200 OK^@
>>>>> Via: SIP/2.0/UDP
>>>>> 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.0;received=172.30.140.57^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-2f38213d4413f513-1--d87543-;rport=55063^@
>>>>> Record-Route: <sip:172.30.140.57;lr=on>^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 INVITE^@
>>>>> User-Agent: Asterisk PBX^@
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY^@
>>>>> Supported: replaces^@
>>>>> Contact: <sip:887238976894563045 at 172.30.140.40>^@
>>>>> Content-Type: application/sdp^@
>>>>> Content-Length: 240^@
>>>>> ^@
>>>>> v=0^@
>>>>> o=root 1966 1966 IN IP4 172.30.140.40^@
>>>>> s=session^@
>>>>> c=IN IP4 172.30.140.40^@
>>>>> t=0 0^@
>>>>> m=audio 18852 RTP/AVP 0 101^@
>>>>> a=rtpmap:0 PCMU/8000^@
>>>>> a=rtpmap:101 telephone-event/8000^@
>>>>> a=fmtp:101 0-16^@
>>>>> a=silenceSupp:off - - - -^@
>>>>> a=ptime:20^@
>>>>> a=sendrecv^@
>>>>>
>>>>> U 2011/02/17 11:53:03.298702 172.30.140.57:5060 -> 172.30.140.18:55063
>>>>> SIP/2.0 200 OK^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-2f38213d4413f513-1--d87543-;rport=55063^@
>>>>> Record-Route: <sip:172.30.140.57;lr=on>^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 INVITE^@
>>>>> User-Agent: Asterisk PBX^@
>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY^@
>>>>> Supported: replaces^@
>>>>> Contact: <sip:887238976894563045 at 172.30.140.40>^@
>>>>> Content-Type: application/sdp^@
>>>>> Content-Length: 240^@
>>>>> ^@
>>>>> v=0^@
>>>>> o=root 1966 1966 IN IP4 172.30.140.40^@
>>>>> s=session^@
>>>>> c=IN IP4 172.30.140.40^@
>>>>> t=0 0^@
>>>>> m=audio 18852 RTP/AVP 0 101^@
>>>>> a=rtpmap:0 PCMU/8000^@
>>>>> a=rtpmap:101 telephone-event/8000^@
>>>>> a=fmtp:101 0-16^@
>>>>> a=silenceSupp:off - - - -^@
>>>>> a=ptime:20^@
>>>>> a=sendrecv^@
>>>>>
>>>>> #
>>>>> U 2011/02/17 11:53:03.407685 *172.30.140.18:55063 ->
>>>>> 172.30.140.57:5060*
>>>>> *ACK sip:887238976894563045 at 172.30.140.40 SIP/2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;branch=z9hG4bK-d87543-521a2b0fde4fec7e-1--d87543-;rport^@*
>>>>> Max-Forwards: 70^@
>>>>> Route: <sip:172.30.140.57;lr>^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 ACK^@
>>>>> Proxy-Authorization: Digest
>>>>> username="1000",realm="172.30.140.57",nonce="4d5cfe2b0000000225b0486d17b27e44f8d7c14d191f0ae7",uri="
>>>>> sip:011887238976894563045 at 172.30.140.57
>>>>> ",response="6c7defa53d5c68c1f3d2b5fda8400be6",algorithm=MD5^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 0^@
>>>>>
>>>>> U 2011/02/17 11:53:03.407995 *172.30.140.57:5060 -> 172.30.140.57:5060
>>>>> *
>>>>> *ACK sip:172.30.140.57;lr SIP/2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-521a2b0fde4fec7e-1--d87543-;rport=55063^@
>>>>> *
>>>>> Max-Forwards: 69^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 ACK^@
>>>>> Proxy-Authorization: Digest
>>>>> username="1000",realm="172.30.140.57",nonce="4d5cfe2b0000000225b0486d17b27e44f8d7c14d191f0ae7",uri="
>>>>> sip:011887238976894563045 at 172.30.140.57
>>>>> ",response="6c7defa53d5c68c1f3d2b5fda8400be6",algorithm=MD5^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 0^@
>>>>> ^@
>>>>>
>>>>> #
>>>>> U 2011/02/17 11:53:03.408064 *172.30.140.57:5060 -> 172.30.140.57:5060
>>>>> *
>>>>> *ACK sip:172.30.140.57;lr SIP/2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-521a2b0fde4fec7e-1--d87543-;rport=55063^@
>>>>> *
>>>>> Max-Forwards: 68^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 ACK^@
>>>>> Proxy-Authorization: Digest
>>>>> username="1000",realm="172.30.140.57",nonce="4d5cfe2b0000000225b0486d17b27e44f8d7c14d191f0ae7",uri="
>>>>> sip:011887238976894563045 at 172.30.140.57
>>>>> ",response="6c7defa53d5c68c1f3d2b5fda8400be6",algorithm=MD5^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 0^@
>>>>>
>>>>> U 2011/02/17 11:53:03.408099 *172.30.140.57:5060 -> 172.30.140.57:5060
>>>>> *
>>>>> *ACK sip:172.30.140.57;lr SIP/2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-521a2b0fde4fec7e-1--d87543-;rport=55063^
>>>>> *@
>>>>> Max-Forwards: 67^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 ACK^@
>>>>> Proxy-Authorization: Digest
>>>>> username="1000",realm="172.30.140.57",nonce="4d5cfe2b0000000225b0486d17b27e44f8d7c14d191f0ae7",uri="
>>>>> sip:011887238976894563045 at 172.30.140.57
>>>>> ",response="6c7defa53d5c68c1f3d2b5fda8400be6",algorithm=MD5^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 0^@
>>>>> ^@
>>>>>
>>>>> #
>>>>> U 2011/02/17 11:53:03.408129 *172.30.140.57:5060 -> 172.30.140.57:5060
>>>>> *
>>>>> *ACK sip:172.30.140.57;lr SIP/2.0^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.57;branch=z9hG4bKbf24.2b64a8c2.2^@
>>>>> Via: SIP/2.0/UDP 172.30.140.18:55063
>>>>> ;received=172.30.140.18;branch=z9hG4bK-d87543-521a2b0fde4fec7e-1--d87543-;rport=55063^@
>>>>> *
>>>>> Max-Forwards: 66^@
>>>>> Contact: <sip:1000 at 172.30.140.18:55063>^@
>>>>> To: "011887238976894563045"<sip:011887238976894563045 at 172.30.140.57
>>>>> >;tag=as2d96f902^@
>>>>> From: "1000"<sip:1000 at 172.30.140.57>;tag=f8636d21^@
>>>>> Call-ID: NjM0ZDU0NmNkOTI2YWZmYjk4MzBlY2Y2ZmJhM2YxYjU.^@
>>>>> CSeq: 2 ACK^@
>>>>> Proxy-Authorization: Digest
>>>>> username="1000",realm="172.30.140.57",nonce="4d5cfe2b0000000225b0486d17b27e44f8d7c14d191f0ae7",uri="
>>>>> sip:011887238976894563045 at 172.30.140.57
>>>>> ",response="6c7defa53d5c68c1f3d2b5fda8400be6",algorithm=MD5^@
>>>>> User-Agent: X-Lite release 1011s stamp 41150^@
>>>>> Content-Length: 0^@
>>>>> .
>>>>> .
>>>>> .
>>>>> .
>>>>>
>>>>> This continues until the Asterisk retransmit the 200 OK, but then the
>>>>> same behavior, the Proxy sends the ACK from A to itself...what is happening?
>>>>> what should i check?
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110224/ed61cf86/attachment-0001.htm>
More information about the Users
mailing list