Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote:
> Managed to fix it (modified all the names in the user database so that
> they authenticate with full sip URI (u...@sip_server)
> e.g. :
> {user, [{name, "noet...@gottingen.exp.org"},...
> instead of just
> {user, [{name, "Noether"},...
>
> I do not know why it works with the UAs I am using better this way.
Strange beyond belief. You should compare logs. The SIP username has
absolutely _nothing_ to do with UDP datagrams. Something else must have
changed too.
> Many thanks for the advices and pointing where to look.
You are welcome. Glad that you got it working.
> An additional question, from what I read pstnproxy translates from sip
> URIs to e164 numbers and forwards everything to a pstn gateway.
> So, from my understanding it does not include any media gateway
> functionality, all of it being taken care by the external pstn gw.
> Is this correct?
Correct. YXA only speaks SIP (well, a tiny bit of STUN too).
/Fredrik
___
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Managed to fix it (modified all the names in the user database so that
they authenticate with full sip URI (u...@sip_server)
e.g. :
{user, [{name, "noet...@gottingen.exp.org"},...
instead of just
{user, [{name, "Noether"},...
I do not know why it works with the UAs I am using better this way.
Many thanks for the advices and pointing where to look.
An additional question, from what I read pstnproxy translates from sip
URIs to e164 numbers and forwards everything to a pstn gateway.
So, from my understanding it does not include any media gateway
functionality, all of it being taken care by the external pstn gw.
Is this correct?
Regards,
--
Costin-Tiberiu RADU
În data de Lu, 23-03-2009 la 08:30 +0100, Fredrik Thulin a scris:
> Costin-Tiberiu RADU wrote:
> ...
> > What is most intreaguing to me is that despite the information seems to
> > exist in the user database in yxa, still, when an INVITE comes from one
> > of the users to the other, yxa does not know how to find it.
>
> Sure it does - YXA just doesn't manage to send UDP datagrams to one of
> the user agents.
>
> > Regarding the operating system, I use FreeBSD 7.1 with erlang version
> > 5.6.4 and for yxa I used the latest version from cvs.
>
> Ok.
>
> This is most likely not relevant, but I do remember that *BSD had some
> issues with detecting the interface IP address(es). Try starting
> incomingproxy with "-d" to get to the erlang shell again, and execute
> "siphost:myip()." and "siphost:myip_list()". The expected results would
> be along these lines :
>
>(incomingpr...@host.name)1> siphost:myip().
>"192.168.34.149"
>(incomingpr...@host.name)2> siphost:myip_list().
>["192.168.34.149"]
>(incomingpr...@host.name)3>
>
> > Do you know of any working deployment of the cvs version (or version 1+
> > for that matter) ?
>
> Yes, I have multiple working installations on Linux.
>
> I don't think your problem is related to YXA at all. It is more likely
> that it is a problem with Erlang on FreeBSD. To determine this, try the
> following simple steps for sending UDP datagrams :
>
>1> {ok, Socket} = gen_udp:open(, [{reuseaddr, true}, binary]).
>{ok,#Port<0.1305>}
>2> gen_udp:send(Socket, "192.168.34.148", 5061, "test").
>ok
>3>
>
> If that works (meaning : returns ok instead of eaddrnotavail) try the
> same with a socket bound to the same IP address YXA would have bound to :
>
>1> {ok, MyIP} = inet_parse:ipv4_address(siphost:myip()),
> {ok, Socket1} = gen_udp:open(7778, [{ip, MyIP},
> {reuseaddr, true}, binary]).
>{ok,#Port<0.1309>}
>2> gen_udp:send(Socket1, "192.168.34.148", 5061, "test").
>
>ok
>3>
Yes , it works sending udp datagrams.
>
>
> /Fredrik
> ___
> Yxa-devel mailing list
> Yxa-devel@lists.su.se
> https://lists.su.se/mailman/listinfo/yxa-devel
>
signature.asc
Description: Aceast fragment din mesaj este semnat digital
___
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote:
...
> What is most intreaguing to me is that despite the information seems to
> exist in the user database in yxa, still, when an INVITE comes from one
> of the users to the other, yxa does not know how to find it.
Sure it does - YXA just doesn't manage to send UDP datagrams to one of
the user agents.
> Regarding the operating system, I use FreeBSD 7.1 with erlang version
> 5.6.4 and for yxa I used the latest version from cvs.
Ok.
This is most likely not relevant, but I do remember that *BSD had some
issues with detecting the interface IP address(es). Try starting
incomingproxy with "-d" to get to the erlang shell again, and execute
"siphost:myip()." and "siphost:myip_list()". The expected results would
be along these lines :
(incomingpr...@host.name)1> siphost:myip().
"192.168.34.149"
(incomingpr...@host.name)2> siphost:myip_list().
["192.168.34.149"]
(incomingpr...@host.name)3>
> Do you know of any working deployment of the cvs version (or version 1+
> for that matter) ?
Yes, I have multiple working installations on Linux.
I don't think your problem is related to YXA at all. It is more likely
that it is a problem with Erlang on FreeBSD. To determine this, try the
following simple steps for sending UDP datagrams :
1> {ok, Socket} = gen_udp:open(, [{reuseaddr, true}, binary]).
{ok,#Port<0.1305>}
2> gen_udp:send(Socket, "192.168.34.148", 5061, "test").
ok
3>
If that works (meaning : returns ok instead of eaddrnotavail) try the
same with a socket bound to the same IP address YXA would have bound to :
1> {ok, MyIP} = inet_parse:ipv4_address(siphost:myip()),
{ok, Socket1} = gen_udp:open(7778, [{ip, MyIP},
{reuseaddr, true}, binary]).
{ok,#Port<0.1309>}
2> gen_udp:send(Socket1, "192.168.34.148", 5061, "test").
ok
3>
/Fredrik
___
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
My setup looks like this: All three PCs are connected to the same ethernet network 192.168.34.0/24 gottingen.exp.org .149 | Gauss Riemann .148 .146 .149 also acts as a DNS server for the small network. All the hosts see each other (actually, I have at all time ssh sessions to all of the PCs ). Plus, in the scenario both users Riemann and Gauss register before I try to initiate anything. What is most intreaguing to me is that despite the information seems to exist in the user database in yxa, still, when an INVITE comes from one of the users to the other, yxa does not know how to find it. Regarding the operating system, I use FreeBSD 7.1 with erlang version 5.6.4 and for yxa I used the latest version from cvs. Do you know of any working deployment of the cvs version (or version 1+ for that matter) ? Best regards and thanks for the help -- Costin-Tiberiu RADU În data de Vi, 20-03-2009 la 10:39 +0100, Fredrik Thulin a scris: > Costin-Tiberiu RADU wrote: > > Thanks a lot for the help. > > I attached all the config files (including for the dns zone (I called it > > exp.org (from experimental - i.e. it has nothing to do with any real > > domain))). > > And yes I did what you suggested, and increased the udp max size to over > > 3000. > > Thank you for providing all the information at once. > > I had a look, and yes - YXA fails to send UDP packets to > udp:192.168.34.148:5061 with an error of eaddrnotavail. This is strange, > and I have no idea what that really means (does 192.168.34.148 respond > to pings from the SIP server? What operating system is the server using?). > > However, you are REGISTERing user *Riemann* at 192.168.34.146:5065 > >2009-03-18 23:05:39.186 > normal<0.193.0>:z9hG4bK-yxa-c6dx8uo1ykc2q1ugyiy1og: > incomingproxy: REGISTER Riemann at > sip:riem...@192.168.34.146:5065;transport=udp > (priority 100, expire in 3600) > > but you are trying to INVITE user *Gauss* > >2009-03-18 23:05:42.901 > normal<0.202.0>:z9hG4bK-yxa-louzmlxf5ksy0rqytrrlgw-UAS INVITE: > INVITE sip:ga...@gottingen.exp.org [client=udp:192.168.34.146:5066, > from=, > to=] > > and apparently, there is information in your location database that user > Gauss can be reached at 192.168.34.148:5061 (note IP *148*, not *146*) > >2009-03-18 23:05:42.911 debug<0.201.0>:Routing: lookupuser on > "sip:ga...@gottingen.exp.org" -> proxy to > "sip:ga...@192.168.34.148:5061;transport=udp" > > /Fredrik > ___ > Yxa-devel mailing list > Yxa-devel@lists.su.se > https://lists.su.se/mailman/listinfo/yxa-devel > signature.asc Description: Aceast fragment din mesaj este semnat digital ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote: > Thanks a lot for the help. > I attached all the config files (including for the dns zone (I called it > exp.org (from experimental - i.e. it has nothing to do with any real > domain))). > And yes I did what you suggested, and increased the udp max size to over > 3000. Thank you for providing all the information at once. I had a look, and yes - YXA fails to send UDP packets to udp:192.168.34.148:5061 with an error of eaddrnotavail. This is strange, and I have no idea what that really means (does 192.168.34.148 respond to pings from the SIP server? What operating system is the server using?). However, you are REGISTERing user *Riemann* at 192.168.34.146:5065 2009-03-18 23:05:39.186 normal<0.193.0>:z9hG4bK-yxa-c6dx8uo1ykc2q1ugyiy1og: incomingproxy: REGISTER Riemann at sip:riem...@192.168.34.146:5065;transport=udp (priority 100, expire in 3600) but you are trying to INVITE user *Gauss* 2009-03-18 23:05:42.901 normal<0.202.0>:z9hG4bK-yxa-louzmlxf5ksy0rqytrrlgw-UAS INVITE: INVITE sip:ga...@gottingen.exp.org [client=udp:192.168.34.146:5066, from=, to=] and apparently, there is information in your location database that user Gauss can be reached at 192.168.34.148:5061 (note IP *148*, not *146*) 2009-03-18 23:05:42.911 debug<0.201.0>:Routing: lookupuser on "sip:ga...@gottingen.exp.org" -> proxy to "sip:ga...@192.168.34.148:5061;transport=udp" /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote: > I agree this is expected behaviour from a UA. > The problem is that when I try to initiate a SIP session calling from > one UA the other one, using yxa as a proxy, incomingproxy reports 500 No > reacheable destination to the caller. > From this behaviour I understand that although everything is fine > (authentication went fine, yxa creates the entries in the mnesia > database), however it does not know how to reach the UAs. > > This is my problem I am trying to figure out. Ok, thanks for clarifying. I've had two very busy days, so perhaps I have missed you telling me this already, but have you tried what I said about increasing the size limit for when YXA chooses TCP to contact the UA instead of UDP? If so, can you provide me with full incomingproxy.debug logs for a REGISTER followed by an INVITE to the UA that just registered? /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
I agree this is expected behaviour from a UA. The problem is that when I try to initiate a SIP session calling from one UA the other one, using yxa as a proxy, incomingproxy reports 500 No reacheable destination to the caller. From this behaviour I understand that although everything is fine (authentication went fine, yxa creates the entries in the mnesia database), however it does not know how to reach the UAs. This is my problem I am trying to figure out. Regards -- Costin-Tiberiu RADU În data de Mi, 18-03-2009 la 12:59 +0100, Fredrik Thulin a scris: > Costin-Tiberiu RADU wrote: > > Configured a DNS server for a fictional domain (separated the network > > from internet - at this moment it is experimental setup) (including with > > ORIGIN entries with NAPTR ) > > Configured incomingproxy.config for the new domain. > > Configured /var/yxa/userdb with the new domain in the URI of the users. > > > > All well and fine. > > > > I tried again to register with ekiga. It replies 200 OK, however when I > > list with phone:list_phones() all the contacts are listed with > > usern...@192.168.34.* > > Retried with SJphone from windows, with kphone as well. > > Same behaviour. > > The UA, following the registration process, asks the server to be > > registered with the contact URI usern...@ip_address > > > > Any idea why this behaviour and what I may have missed ? > > That's what UA:s typically do - what did you expect? I do not understand > what problem you are trying to solve here... > > The location database (mnesia table called 'phone' in YXA) effectively > stores the Contact header content from the clients REGISTER message. > Clients say where they can be reached in the Contact header of REGISTERs > (what they think is their _location_, that is). > > /Fredrik > > ___ > Yxa-devel mailing list > Yxa-devel@lists.su.se > https://lists.su.se/mailman/listinfo/yxa-devel > signature.asc Description: Aceast fragment din mesaj este semnat digital ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote: > Configured a DNS server for a fictional domain (separated the network > from internet - at this moment it is experimental setup) (including with > ORIGIN entries with NAPTR ) > Configured incomingproxy.config for the new domain. > Configured /var/yxa/userdb with the new domain in the URI of the users. > > All well and fine. > > I tried again to register with ekiga. It replies 200 OK, however when I > list with phone:list_phones() all the contacts are listed with > usern...@192.168.34.* > Retried with SJphone from windows, with kphone as well. > Same behaviour. > The UA, following the registration process, asks the server to be > registered with the contact URI usern...@ip_address > > Any idea why this behaviour and what I may have missed ? That's what UA:s typically do - what did you expect? I do not understand what problem you are trying to solve here... The location database (mnesia table called 'phone' in YXA) effectively stores the Contact header content from the clients REGISTER message. Clients say where they can be reached in the Contact header of REGISTERs (what they think is their _location_, that is). /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Configured a DNS server for a fictional domain (separated the network from internet - at this moment it is experimental setup) (including with ORIGIN entries with NAPTR ) Configured incomingproxy.config for the new domain. Configured /var/yxa/userdb with the new domain in the URI of the users. All well and fine. I tried again to register with ekiga. It replies 200 OK, however when I list with phone:list_phones() all the contacts are listed with usern...@192.168.34.* Retried with SJphone from windows, with kphone as well. Same behaviour. The UA, following the registration process, asks the server to be registered with the contact URI usern...@ip_address Any idea why this behaviour and what I may have missed ? Best regards and many thanks -- Costin-Tiberiu RADU signature.asc Description: Aceast fragment din mesaj este semnat digital ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
I tried also with an enlarger UDP packet and still no success. It appears it is a DNS only problem, as the UA queries the DNS server for _sip._udp.domain Do you know if in successfull deployments of yxa is it possible to use a SIP server without the use of an DNS server ? În data de Sb, 14-03-2009 la 16:44 +0100, Fredrik Thulin a scris: > Costin-Tiberiu RADU wrote: > ... > > > > debug<0.331.0>:Transport layer: Failed sending request (1353 bytes) to udp: > > 192.168.34.148:5069, error eaddrnotavail > > I've never seen an eaddrnotavail before - not sure what that is. Do you > have some kind of exotic interface connection, like IP aliases on the > server or similar? What operating system? > > ... > > 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. > > Well, if that is the case then the clients are not using their real > addresses in the Contact header of the REGISTER messages, when > registering. Otherwise, the problem is more likely to be that YXA for > some reason can't send UDP datagrams to the client. > > Did you try what I suggested about udp_max_datagram_size? The "Failed > sending request (1353 bytes) to udp:" further suggests that the problem > might be that the INVITE is larger than 1200 bytes, which is the default > limit for udp_max_datagram_size. Tried with 3000, no success. > > > Is there a way I can see which users are at a given moment registered ? > > (besides direct queries to the mnesia database) > > Set up the web interface, or start incomingproxy with "-d" to get an > erlang shell. At the erlang shell prompt, enter > >phone:list_phones(). Thanks, this was very helpfull. > > /Fredrik signature.asc Description: Aceast fragment din mesaj este semnat digital ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote: ... > > debug<0.331.0>:Transport layer: Failed sending request (1353 bytes) to udp: > 192.168.34.148:5069, error eaddrnotavail I've never seen an eaddrnotavail before - not sure what that is. Do you have some kind of exotic interface connection, like IP aliases on the server or similar? What operating system? ... > 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. Well, if that is the case then the clients are not using their real addresses in the Contact header of the REGISTER messages, when registering. Otherwise, the problem is more likely to be that YXA for some reason can't send UDP datagrams to the client. Did you try what I suggested about udp_max_datagram_size? The "Failed sending request (1353 bytes) to udp:" further suggests that the problem might be that the INVITE is larger than 1200 bytes, which is the default limit for udp_max_datagram_size. > Is there a way I can see which users are at a given moment registered ? > (besides direct queries to the mnesia database) Set up the web interface, or start incomingproxy with "-d" to get an erlang shell. At the erlang shell prompt, enter phone:list_phones(). /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
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'
: 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
> 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
Re: [Yxa-devel] YXA setup questions
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
Re: [Yxa-devel] YXA setup questions
I solved (sort of accidentally) the authentication problem . (configuration problem of the userdb). 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: """ 2009-03-14 12:11:34.906 normal<0.491.0>:z9hG4bK-yxa-7fwxs4ikwikm6e+b7mnzza-UAS INVITE: INVITE sip:ga...@gottingen.student.com.dtu.dk[client=udp: 192.168.34.146:5065, from=>, to= >] 2009-03-14 12:11:34.911 normal<0.490.0>:z9hG4bK-yxa-7fwxs4ikwikm6e+b7mnzza: incomingproxy: From: address requires authentication 2009-03-14 12:11:34.913 normal<0.491.0>:z9hG4bK-yxa-7fwxs4ikwikm6e+b7mnzza-UAS INVITE: Responding '407 Proxy Authentication Required' 2009-03-14 12:11:34.923 normal<0.491.0>:z9hG4bK-yxa-7fwxs4ikwikm6e+b7mnzza-UAS INVITE: Response '407 Proxy Authentication Required' to request INVITE sip:ga...@gottingen.student.com.dtu.dkACK-ed 2009-03-14 12:11:34.934 normal<0.494.0>:z9hG4bK-yxa-dewgpmysa85uimbbfrwoow-UAS INVITE: INVITE sip:ga...@gottingen.student.com.dtu.dk[client=udp: 192.168.34.146:5065, from=>, to= >] 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 normal<0.494.0>:z9hG4bK-yxa-dewgpmysa85uimbbfrwoow-UAS INVITE: Responding '500 No reachable destination' 2009-03-14 12:11:34.970 normal<0.494.0>:z9hG4bK-yxa-dewgpmysa85uimbbfrwoow-UAS INVITE: Response '500 No reachable destination' to request INVITE sip:ga...@gottingen.student.com.dtu.dkACK-ed """ Best regards and thanks for the help 2009/3/13 Fredrik Thulin > Costin-Tiberiu RADU wrote: > >> Checked. >> >> And partially solved the problem. >> >> The problem is that the server does not want to register ekiga. >> >> On the other hand wehn I tried with kphone the registration worked. >> >> However, when trying to place a call, even if all the parties registrated >> successfully (both received a 200 OK message) the server sais that it does >> not know how to find the other party. >> >> (and yes I checked the logs, and the configs, and the next step is digging >> through the source files to >> > > Can you perhaps share logs showing these two problems? > > YXA is usually very interoperable with clients, so Ekiga should work as > well as anything else. > > If there is a NAT between your clients and the registrar (incomingproxy), > you might want to try setting up an outgoingproxy application and configure > your clients to REGISTER through the outgoingproxy. > > /Fredrik > incomingproxy.config Description: Binary data userdb Description: Binary data ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote: > Checked. > > And partially solved the problem. > > The problem is that the server does not want to register ekiga. > > On the other hand wehn I tried with kphone the registration worked. > > However, when trying to place a call, even if all the parties registrated > successfully (both received a 200 OK message) the server sais that it does > not know how to find the other party. > > (and yes I checked the logs, and the configs, and the next step is digging > through the source files to Can you perhaps share logs showing these two problems? YXA is usually very interoperable with clients, so Ekiga should work as well as anything else. If there is a NAT between your clients and the registrar (incomingproxy), you might want to try setting up an outgoingproxy application and configure your clients to REGISTER through the outgoingproxy. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Checked. And partially solved the problem. The problem is that the server does not want to register ekiga. On the other hand wehn I tried with kphone the registration worked. However, when trying to place a call, even if all the parties registrated successfully (both received a 200 OK message) the server sais that it does not know how to find the other party. (and yes I checked the logs, and the configs, and the next step is digging through the source files to 2009/3/13 Fredrik Thulin > Costin-Tiberiu RADU wrote: > >> Hi all, >> >> I started again to play with yxa and on a simple setup (with user >> authentication, one server and 2 users) no matter what I do (obviously >> not enough) >> I can't seem to be able to authenticate. >> The best answer I get is something like >> "401 Authentication required" >> "From address requires authentication" >> "407 Proxy Authentication reuired" >> >> Besides this I can't seem to be able to find out why the users >> configured in the /var/yxa/userdb cannot authenticate. >> Any ideas how I can find out why this is not working? >> Thanks and sorry for the noob question. >> > > Yes, one idea immediately comes to mind. Check the log files. > > /Fredrik > ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] YXA setup questions
Costin-Tiberiu RADU wrote: > Hi all, > > I started again to play with yxa and on a simple setup (with user > authentication, one server and 2 users) no matter what I do (obviously > not enough) > I can't seem to be able to authenticate. > The best answer I get is something like > "401 Authentication required" > "From address requires authentication" > "407 Proxy Authentication reuired" > > Besides this I can't seem to be able to find out why the users > configured in the /var/yxa/userdb cannot authenticate. > Any ideas how I can find out why this is not working? > Thanks and sorry for the noob question. Yes, one idea immediately comes to mind. Check the log files. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
[Yxa-devel] YXA setup questions
Hi all, I started again to play with yxa and on a simple setup (with user authentication, one server and 2 users) no matter what I do (obviously not enough) I can't seem to be able to authenticate. The best answer I get is something like "401 Authentication required" "From address requires authentication" "407 Proxy Authentication reuired" Besides this I can't seem to be able to find out why the users configured in the /var/yxa/userdb cannot authenticate. Any ideas how I can find out why this is not working? Thanks and sorry for the noob question. Best regards -- Costin-Tiberiu RADU signature.asc Description: Aceast fragment din mesaj este semnat digital ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
