2009-03-14 15:28:38.978 debug<0.320.0>:Transaction layer: Telling SIP
message handler to start this applications request function.
2009-03-14 15:28:38.980 debug<0.320.0>:Auth: get_user_verified_proxy: No
Proxy-Authorization header, returning false
2009-03-14 15:28:38.980 normal<0.320.0>:z9hG4bK-yxa-9v4lqvfpyah4mghlm5iiqq:
incomingproxy: From: address requires authentication
2009-03-14 15:28:38.981 debug<0.321.0>:UAS decision: Requested to send
3/4/5/6xx response 407 to INVITE when in state 'proceeding' - doing so
(reliably) and entering state 'completed'
2009-03-14 15:28:38.981
normal<0.321.0>:z9hG4bK-yxa-9v4lqvfpyah4mghlm5iiqq-UAS INVITE: Responding
'407 Proxy Authentication Required'
2009-03-14 15:28:38.983
debug<0.321.0>:z9hG4bK-yxa-9v4lqvfpyah4mghlm5iiqq-UAS INVITE: Sending
response to 'INVITE
sip:riem...@gottingen.student.com.dtu.dk<sip%3ariem...@gottingen.student.com.dtu.dk>'
: 407 Proxy Authentication Required



 debug<0.331.0>:Transport layer: Failed sending request (1353 bytes) to udp:
192.168.34.148:5069, error eaddrnotavail

and from there ...

debug<0.331.0>:z9hG4bK-yxa-x7bofw3kafvsd9ew+b1p_q-UAC INVITE: INVITE
sip:ga...@192.168.34.148:5069;transport=udp - pretend we got an '503 Service
Unavailable' (and enter SIP state terminated)
2009-03-14 15:29:03.622 debug<0.331.0>:Siptimer: Cancelling all timers :
2009-03-14 15:29:03.623
debug<0.331.0>:z9hG4bK-yxa-x7bofw3kafvsd9ew+b1p_q-UAC INVITE: Client
transaction telling parent <0.329.0> about response '503 Service
Unavailable'
2009-03-14 15:29:03.624 debug<0.329.0>:sippipe: Received final response '503
Service Unavailable'
2009-03-14 15:29:03.624 debug<0.329.0>:sippipe: There are no more
destinations to try for this target - telling server transaction to answer
500 No reachable destination
2009-03-14 15:29:03.623
debug<0.331.0>:z9hG4bK-yxa-x7bofw3kafvsd9ew+b1p_q-UAC INVITE: Client
transaction (INVITE sip:ga...@192.168.34.148:5069;transport=udp) terminating
in state 'terminated', created response 503 Service Unavailable
2009-03-14 15:29:03.624
debug<0.331.0>:z9hG4bK-yxa-x7bofw3kafvsd9ew+b1p_q-UAC INVITE: Informing my
parent (<0.329.0>) that I am terminating now
2009-03-14 15:29:03.625 debug<0.122.0>:Transaction layer: Received normal
exit-signal from process <0.331.0>
2009-03-14 15:29:03.626 debug<0.330.0>:UAS decision: Requested to send
3/4/5/6xx response 500 to INVITE when in state 'proceeding' - doing so
(reliably) and entering state 'completed'
2009-03-14 15:29:03.626
normal<0.330.0>:z9hG4bK-yxa-x7bofw3kafvsd9ew+b1p_q-UAS INVITE: Responding
'500 No reachable destination'


.....


>From this behavior  I  understand that despite the server sending 200 OK
messages upon registration to the two UAs, when it comes down to allowing
them to talk to each other it does not know where they are.

Is there a way I can see which users are at a given moment registered ?
(besides direct queries to the mnesia database)

Regards, and thanks for the quick response.

Costin-Tiberiu Radu




2009/3/14 Fredrik Thulin <f...@it.su.se>

> Costin-Tiberiu RADU wrote:
>
>> I solved (sort of accidentally) the authentication problem .
>> (configuration
>> problem of the userdb).
>>
>
> Good.
>
>  The clients are all in the same subnet. They all know of each other via
>> /etc/hosts
>> (ping, ssh, whatever other protocol works, so connectivity is not a
>> problem,
>> and no NAT is in between)
>>
>> Still, I cannot initiate a SIP session.
>> I attached the config files.
>> You can see below what yxa prints while in debug mode when I try to
>> initiate
>> a call:
>>
>>  ...
>
> This is actually not the debug logs (all have priority 'normal') - go look
> in the incomingproxy.debug file for additional details. Look around the
> timestamp of the following lines :
>
>  2009-03-14 12:11:34.944
>> normal<0.493.0>:z9hG4bK-yxa-dewgpmysa85uimbbfrwoow:
>> incomingproxy: Proxy INVITE -> sip:ga...@192.168.34.148:5061
>> ;transport=udp
>> 2009-03-14 12:11:34.947
>> normal<0.495.0>:z9hG4bK-yxa-dewgpmysa85uimbbfrwoow-UAC INVITE: Sending
>> INVITE sip:ga...@192.168.34.148:5061;transport=udp (to tcp:
>> 192.168.34.148:5061)
>> 2009-03-14 12:11:34.954
>> normal<0.495.0>:z9hG4bK-yxa-dewgpmysa85uimbbfrwoow-UAC INVITE: Transport
>> layer failed sending INVITE sip:ga...@192.168.34.148:5061;transport=udp
>> to
>> tcp:192.168.34.148:5061, pretend we got an '503 Service Unavailable'
>> 2009-03-14 12:11:34.958
>>
>
> What I can tell from this is that YXA chooses to try to send the INVITE
> using tcp "(to tcp:192.168.34.148:5061)" although the client seems to have
> registered using UDP ("transport=udp"). The incomingproxy.debug output
> should confirm this.
>
> I'm guessing a bit here, but I guess that you will see in the debug logs
> that the INVITE is too large to be sent using UDP (while being standards
> compliant), so YXA chooses TCP. The client however, is not RFC3261 compliant
> and does not implement TCP and the INVITE fails.
>
> Sometimes breaking the standards improve interoperability. Try setting the
> configuration parameter udp_max_datagram_size to 3000 or similar. If my
> guess about what is going on here is correct, that would probably "solve"
> your problem.
>
> /Fredrik
>
> PS. The README has a typo for that configuration parameter, it talks about
> "before switching from TCP to UDP" when it should be the opposite, from UDP
> to TCP.
>
_______________________________________________
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel

Reply via email to