Re: [OpenSIPS-Users] Registrar not saving received from Path header
Hello Nathaniel, See http://www.opensips.org/html/docs/modules/1.9.x/registrar.html#id248705 - this controls the PATH support in REGISTRAR module. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/04/2013 01:31 AM, Nathaniel L Keeling III wrote: Hello, I sent an earlier post concerning NATed registrations not being able to locate from the lookup() function when the registration request is sent from a opensips proxy server to an opensips registration server and from my research it looks like I should be using the Path header with the received parameter set. Doing this, the Register request is sent to the registrar proxy server with a Path header, the user is successfully authorized and saved in the location table but when I look at the location table entry, the received column either does not contain a value or it contains the wrong value. Here is the Register request sent from the proxy to the registrar server and the output from the location table. REGISTER sip:my-sip-domain.com;transport=tcp SIP/2.0. Call-ID: 541d070a84f74ca6f61f68732d063d35@0:0:0:0:0:0:0:0. CSeq: 2 REGISTER. From: "Nathaniel L Keeling III" ;tag=cbe17bd3. To: "Nathaniel L Keeling III" . Max-Forwards: 68. User-Agent: Jitsi2.0.4506.10553Mac OS X. Expires: 600. Contact: "Nathaniel L Keeling III" ;expires=600. Via: SIP/2.0/UDP xxx.xxx.110.38:5060;branch=z9hG4bK-383637-fa379c63d9b82d3f671742fe537882a1;i=04. Via: SIP/2.0/TCP 192.168.43.237:65457;received=208.54.44.148;branch=z9hG4bK-383637-fa379c63d9b82d3f671742fe537882a1. Authorization: Digest username="nkeeling3",realm="mydomain2.com",nonce="5184345b003b08c40d29a091fb53e6cb83c3961c1dbb",uri="sip:my-sip-domain.com;transport=tcp",response="987edb51f504ff56c7ba840d594c4bb1". Content-Length: 0. Path: . Path: . id | username |domain | contact | received | path | expires | q | callid | cseq | last_modified| flags | cflags | user_agent | socket | methods | sip_instance --+---+---++-+--+-++--+--+-+---++-+-+-+-- 1555 | nkeeling3 | mydomain2.com | sip:nkeeling3@192.168.43.237:65420;transport=tcp;registering_acc=mydomain2_com | sip:xxx.xxx.110.38:5060 | | 2013-05-03 17:08:03 | -1 | 869321ee55e10970ff139673909ab626@0:0:0:0:0:0:0:0 | 10 | 2013-05-03 16:58:03 | 0 | 1024 | Jitsi2.0.4506.10553Mac OS X | udp:xxx.xxx.110.48:5060 | | 1556 | nkeeling3 | mydomain2.com | sip:nkeeling3@192.168.43.237:65457;transport=tcp;registering_acc=mydomain2_com | sip:xxx.xxx.110.38:5060 | | 2013-05-03 17:13:42 | -1 | 541d070a84f74ca6f61f68732d063d35@0:0:0:0:0:0:0:0 |2 | 2013-05-03 17:03:42 | 0 | 1024 | Jitsi2.0.4506.10553Mac OS X | udp:xxx.xxx.110.48:5060 | | Thanks Nathaniel ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] 6xx reply handling and acc
Hello Brett, If the 6xx_blocking is on (by default), when receiving a 6xx reply, TM will select that branch as winning branch and it will not allow any addition of new branches - all will fail (in failure route). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/03/2013 12:04 AM, Brett Nemeroff wrote: Hello list, I have a question about default handling of 6xx replies and acc. I have a 1.8 build that does NOT have disable_6xx_block set (it's just default). I'm seeing cases where when I get a 6xx (after a 18x reply) where failure route causes it to roll to another block, but it'll never t_relay the call out; or I think that is what is happening. So my first carrier attempt results in 18x then 606. I get a 606 for the invite in missed_calls. Then I relay both the 606 and a 500 Server Unavailable 19/SL to the originator. Weird thing is, then missed_calls shows the second carrier it would have tried, but SIP traces show it never did. I guess I"m wondering how the default handing changes the callflow when a failure route is hit with a 6xx reply? Thanks, Brett ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Accounting Invite Retransmissions and NATed Registrations
Hello Nathaniel, In script, for initial requests, you can use t_newtran() (very aggressive approach) or t_check_tras() in order to detect retransmissions. Do that before doing any other particular processing for the INVITE (the idea is to detect the retransmission asap, before doing anything else). t_check_trans() checks if it is a retransmission (by looking into the existing transactions in memory), but does not create a transaction if not a retransmission - the transaction will be created later, by t_relay(). t_newtran() checks and create transaction if not retransmission. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/01/2013 08:03 AM, Nathaniel L Keeling III wrote: Hello, I have a couple of questions I would like to ask. First, I have a client that is sending the initial Invite twice and I would like to know how to detect this within the script? The dual invites are causing double accounting and other minor issue. Second, I have a scenario where I have p1 send all registrations requests to p2 to process requests. Registration of user is successful, but when you try and call the user, opensips can not complete the call even though the user is found in the location table. How can I resolve this. Also, the user is behind a NAT. Thanks Nathaniel L Keeling ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] media-relay error - operation not permitted
Hi Jeff, Have you checked /proc/sys/net/netfilter/nf_conntrack_expect_max? On our (Debian) boxes the default is 256 which is way too low, we set it to 65536. Also, we set it at the end of /etc/rc.local because setting it in /etc/sysctl.conf doesn't seem to work. Regards, Henk Hesselink On 2/21/13 1:11 PM, Saúl Ibarra Corretgé wrote: Hi Jeff, On Feb 8, 2013, at 10:08 PM, Jeff Pyle wrote: Hi Muhammed, On Fri, Feb 8, 2013 at 3:19 PM, Muhammad Shahzad wrote: In my previous experience, i see this error due to one of following reasons. 1. The media ports you have specified in media proxy configuration overlaps some other service port range, e.g. in case you are running media proxy and asterisk on same machine and RTP port range of asterisk overlaps media proxy port range. Asterisk is running on the same machine. /etc/asterisk/rtp.conf contains: rtpstart=16384 rtpend=20480 /etc/mediaproxy/config.ini contains: port_range = 20482:32768 Having said that, one relay machine does see more Asterisk activity than the other. Still it's activity is in the calls-per-minute range, not calls-per-second. 2. Check dmesg, do you see this message or any relevant message from network stack or ethernet driver there? No. The last relevant line is: [ 44.905812] ctnetlink v0.93: registering with nfnetlink. Most "irrelevant" lines are promiscuous mode reports from my tshark testing. Otherwise, [40380457.905028] Machine check events logged The machine's uptime is just over 500 days. 3. Check syslog and see if you get following message or something similar from nf_conntrack. nf_conntrack: table full, dropping packet Nothing of the sort. 4. Check ulimit and selinux, but seems from your previous posts on this issue that they are fine. ulimit is handled by the application itself I believe. selinux has never been configured. 5. Do you have any SNAT or Multicast related rule in iptables? No. There is no *nat table defined at all, only *mangle (to remark DSCP EF) and *filter (basic INPUT security). No mention of multicast anywhere. There is IPv6 but it's not used for this application. Saúl, I'd be happy to add a logging line, but I'm not familiar enough with Python to know what to add where. Guidance is welcome! John provided me with some logs which I've inspected. The problem is still not 100% clear to me but I have a couple of suspicions. I spent some time trying to understand what is going on, since it's really uncommon to get EPERM for a datagram socket. Please find attached a patch which logs and ignores the error. What I'm interested in seeing is if it would actually work if the error is just ignored. You seem to be running an older MediaProxy release, so the attached patch may not apply cleanly. It should be easy to manually apply though. Now, as for the error reason, the only plausible explanation in case no firewall is being used is a problem with traffic pacing. Basically there seems to be a chance of getting EPERM when sending data over a UDP socket in case the sender is too quick and kernel buffers are full. We do have a (undocumented) setting for this: userspace_transmit_every in the [relay] section. The default value is 1, which means every packet would be relayed in user-space until the conntrack rule has been established. Please also test setting that value to 4, which means that only one out of every 4 packets will be sent to the destination. Since bidirectional media is not yet established (otherwise there would be a conntrack rule) this shouldn't be harmful. Recap: please apply the supplied patch and run these tests: - Just run the current config, watch for the log lines and see if audio flows regardless - Set userspace_transmit_every = 4 in the [relay] section of the configuration file Please let me know how testing goes. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] one way audio in voip clients
Iam new to opensips.i have installed successfully opensips on my pc. i have registered two voip clients. but only one way audio is working. please help me from this issue. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPs Radius Accounting.
Hello Everyone,
Sorry to chime in however, we are also working on failed route
accounting using radius.
My impression was that accounting failed sessions was supported by
Radius when patching
the server using CDRTool. Would we still need the above script along
with the failed packets:
http://cdrtool.ag-projects.com/projects/cdrtool/wiki/Installation_Guide
Kind Regards,
Nick.
On 5/2/13, Muhammad Shahzad wrote:
> Something like this,
>
> if (t_check_status("408")) {
> if ( t_local_replied("all") ) {
> # local timeout with no reply received -> fr_timer
> } else if ( t_local_replied("last") ) {
> # timeout with replies received -> fr_inv_timer
> } else {
> # received timeout
> };
> };
> ...
>
> Thank you.
>
>
>
>
> On Thu, May 2, 2013 at 12:29 PM, qasimak...@gmail.com
> wrote:
>
>> Hi,
>>
>> Thanks Bogdan for your reply.
>>
>> Now for my question, I want to keep my STOP event on reply as i have
>> faced
>> issues when generating event on request time. The thing is how should i
>> cater the fact that the device has gone offline and there is no response
>> generated and hence no accounting STOP event.
>>
>> Regards,
>> Qasim
>>
>>
>> On Tue, Apr 30, 2013 at 2:26 PM, Bogdan-Andrei Iancu
>> wrote:
>>
>>> **
>>> Hello,
>>>
>>> All accounting triggers (START/STOP or CDR based) are on replies, so
>>> when
>>> the transaction is completed. Of course, all transactions are terminated
>>> in
>>> OpenSIPS - either by received replies, either by a timeout (if no reply
>>> received).
>>>
>>> If you want to generate the STOP event at BYE request time (versus BYE
>>> reply time), you can manually do it from script via the acc function
>>> acc_db_request() (instead of setting the acc flag and letting the acc
>>> module to generate automatically the event) - the generate event is the
>>> same. See:
>>>
>>> http://www.opensips.org/html/docs/modules/1.9.x/acc.html#id294346
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>> On 04/30/2013 08:00 AM, qasimak...@gmail.com wrote:
>>>
>>> I have tried this scenario. Still if the User B is behind a NAT or is
>>> unreachable the opensips generates the BYE with retransmitted BYE's and
>>> the
>>> dialog is closed but there is no response to BYE received from that user
>>> hence no radius acct request.
>>>
>>> Regards,
>>> Qasim
>>>
>>>
>>> On Mon, Apr 29, 2013 at 8:36 PM, Muhammad Shahzad
>>> wrote:
>>>
Per my understanding, accounting event is sent when BYE completes,
whether if destination replies with 200 OK or BYE re-transmission times
out
and opensips responds with 408 Request timeout. In each case SIP
response
code is set appropriately and you should use stop time as accounting
end
time rather then the time your receive account stop request on radius
(they
both may differ, e.g. under high load scenarios).
Thank you.
On Mon, Apr 29, 2013 at 3:27 PM, qasimak...@gmail.com <
qasimak...@gmail.com> wrote:
>Hi,
>
> I wanted to confirm if radius accounting requests are generated on a
> successful transaction or it can be generated on a received BYE only.
> To
> elaborate my question you can look at 2 diagrams below. Is first
> scenario
> correct based on RFC's? My next question is that if scenario A is
> correct
> then how can we account the call if say user B has gone offline and we
> do
> not receive 200 OK of the BYE sent?
>
> Can we send a manual accounting request to Radius with acc_aaa_request
> in accounting module?
>
> *Scenario A:*
> User AOpenSIPsRadius User B
>
> |---BYE--->|
> |
> |
> |-BYE>|
> | |---acct-BYE--->|
>
> *Scenario B:*
> User AOpenSIPsRadius User B
> |---BYE--->|
> | |
> |
> |-BYE>|
> | |<---200 OK
> -|
> |<200 OK -|
> | |---acct-BYE--->|
>
>
> Regards,
> Qasim Ayyaz Khan
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
Mit freundlichen Grüßen
Muhammad Shahzad
---
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85 <%2B49%20176%2099%2083%2010%2085>
MSN: shari_7
Re: [OpenSIPS-Users] OpenSIPs Radius Accounting.
Hi Nick,
I haven't used Radius with CDRTool so not very sure how the patch effects
OpenSIPS accounting events triggered to Radius. We are using
much sophisticated business logic with integrated VLR and HRL along with
call billing with respect to national and international roaming cases.
Anyhow all you need to do to get failed transactions events in Radius
server, is to set failed_transaction_flag on those transactions, e.g.
modparam("acc", "aaa_flag", 1)
modparam("acc", "failed_transaction_flag", 3)
...
if ((is_method("INVITE") && !has_totag()) || (is_method("BYE"))) {
setflag(1);
setflag(3);
};
...
Then you should get failed transaction events on Radius regardless of
failure reason, e.g. no-answer (480), cancel (487), busy (486) or even
request timeout (408) and so on. This things works out of the box without
patching Radius and / or OpenSIPS.
Thank you.
On Sat, May 4, 2013 at 3:35 PM, Nick Khamis wrote:
> Hello Everyone,
>
> Sorry to chime in however, we are also working on failed route
> accounting using radius.
> My impression was that accounting failed sessions was supported by
> Radius when patching
> the server using CDRTool. Would we still need the above script along
> with the failed packets:
>
> http://cdrtool.ag-projects.com/projects/cdrtool/wiki/Installation_Guide
>
> Kind Regards,
>
> Nick.
>
> On 5/2/13, Muhammad Shahzad wrote:
> > Something like this,
> >
> > if (t_check_status("408")) {
> > if ( t_local_replied("all") ) {
> > # local timeout with no reply received ->
> fr_timer
> > } else if ( t_local_replied("last") ) {
> > # timeout with replies received -> fr_inv_timer
> > } else {
> > # received timeout
> > };
> > };
> > ...
> >
> > Thank you.
> >
> >
> >
> >
> > On Thu, May 2, 2013 at 12:29 PM, qasimak...@gmail.com
> > wrote:
> >
> >> Hi,
> >>
> >> Thanks Bogdan for your reply.
> >>
> >> Now for my question, I want to keep my STOP event on reply as i have
> >> faced
> >> issues when generating event on request time. The thing is how should i
> >> cater the fact that the device has gone offline and there is no response
> >> generated and hence no accounting STOP event.
> >>
> >> Regards,
> >> Qasim
> >>
> >>
> >> On Tue, Apr 30, 2013 at 2:26 PM, Bogdan-Andrei Iancu
> >> wrote:
> >>
> >>> **
> >>> Hello,
> >>>
> >>> All accounting triggers (START/STOP or CDR based) are on replies, so
> >>> when
> >>> the transaction is completed. Of course, all transactions are
> terminated
> >>> in
> >>> OpenSIPS - either by received replies, either by a timeout (if no
> reply
> >>> received).
> >>>
> >>> If you want to generate the STOP event at BYE request time (versus BYE
> >>> reply time), you can manually do it from script via the acc function
> >>> acc_db_request() (instead of setting the acc flag and letting the acc
> >>> module to generate automatically the event) - the generate event is the
> >>> same. See:
> >>>
> >>> http://www.opensips.org/html/docs/modules/1.9.x/acc.html#id294346
> >>>
> >>> Regards,
> >>>
> >>> Bogdan-Andrei Iancu
> >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
> >>>
> >>>
> >>> On 04/30/2013 08:00 AM, qasimak...@gmail.com wrote:
> >>>
> >>> I have tried this scenario. Still if the User B is behind a NAT or is
> >>> unreachable the opensips generates the BYE with retransmitted BYE's and
> >>> the
> >>> dialog is closed but there is no response to BYE received from that
> user
> >>> hence no radius acct request.
> >>>
> >>> Regards,
> >>> Qasim
> >>>
> >>>
> >>> On Mon, Apr 29, 2013 at 8:36 PM, Muhammad Shahzad
> >>> wrote:
> >>>
> Per my understanding, accounting event is sent when BYE completes,
> whether if destination replies with 200 OK or BYE re-transmission
> times
> out
> and opensips responds with 408 Request timeout. In each case SIP
> response
> code is set appropriately and you should use stop time as accounting
> end
> time rather then the time your receive account stop request on radius
> (they
> both may differ, e.g. under high load scenarios).
>
> Thank you.
>
>
>
> On Mon, Apr 29, 2013 at 3:27 PM, qasimak...@gmail.com <
> qasimak...@gmail.com> wrote:
>
> >Hi,
> >
> > I wanted to confirm if radius accounting requests are generated on a
> > successful transaction or it can be generated on a received BYE only.
> > To
> > elaborate my question you can look at 2 diagrams below. Is first
> > scenario
> > correct based on RFC's? My next question is that if scenario A is
> > correct
> > then how can we account the call if say user B has gone offline and
> we
> > do
> > not receive 200 OK of the BYE sent?
> >
> > Can we send a manual accounting request to Radius with
> acc_aaa_request
> > in accountin
Re: [OpenSIPS-Users] OpenSIPs Radius Accounting.
Thank you so much Muhammad. I have that flag already included in our script.
After I sent the last email, I realized that I assumed your use of CDR tool :).
Best of Luck,
Ninus.
On 5/4/13, Muhammad Shahzad wrote:
> Hi Nick,
>
> I haven't used Radius with CDRTool so not very sure how the patch effects
> OpenSIPS accounting events triggered to Radius. We are using
> much sophisticated business logic with integrated VLR and HRL along with
> call billing with respect to national and international roaming cases.
> Anyhow all you need to do to get failed transactions events in Radius
> server, is to set failed_transaction_flag on those transactions, e.g.
>
> modparam("acc", "aaa_flag", 1)
> modparam("acc", "failed_transaction_flag", 3)
>
> ...
>
> if ((is_method("INVITE") && !has_totag()) || (is_method("BYE"))) {
> setflag(1);
> setflag(3);
>
> };
>
> ...
>
>
> Then you should get failed transaction events on Radius regardless of
> failure reason, e.g. no-answer (480), cancel (487), busy (486) or even
> request timeout (408) and so on. This things works out of the box without
> patching Radius and / or OpenSIPS.
>
> Thank you.
>
>
> On Sat, May 4, 2013 at 3:35 PM, Nick Khamis wrote:
>
>> Hello Everyone,
>>
>> Sorry to chime in however, we are also working on failed route
>> accounting using radius.
>> My impression was that accounting failed sessions was supported by
>> Radius when patching
>> the server using CDRTool. Would we still need the above script along
>> with the failed packets:
>>
>> http://cdrtool.ag-projects.com/projects/cdrtool/wiki/Installation_Guide
>>
>> Kind Regards,
>>
>> Nick.
>>
>> On 5/2/13, Muhammad Shahzad wrote:
>> > Something like this,
>> >
>> > if (t_check_status("408")) {
>> > if ( t_local_replied("all") ) {
>> > # local timeout with no reply received ->
>> fr_timer
>> > } else if ( t_local_replied("last") ) {
>> > # timeout with replies received -> fr_inv_timer
>> > } else {
>> > # received timeout
>> > };
>> > };
>> > ...
>> >
>> > Thank you.
>> >
>> >
>> >
>> >
>> > On Thu, May 2, 2013 at 12:29 PM, qasimak...@gmail.com
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> Thanks Bogdan for your reply.
>> >>
>> >> Now for my question, I want to keep my STOP event on reply as i have
>> >> faced
>> >> issues when generating event on request time. The thing is how should
>> >> i
>> >> cater the fact that the device has gone offline and there is no
>> >> response
>> >> generated and hence no accounting STOP event.
>> >>
>> >> Regards,
>> >> Qasim
>> >>
>> >>
>> >> On Tue, Apr 30, 2013 at 2:26 PM, Bogdan-Andrei Iancu
>> >> wrote:
>> >>
>> >>> **
>> >>> Hello,
>> >>>
>> >>> All accounting triggers (START/STOP or CDR based) are on replies, so
>> >>> when
>> >>> the transaction is completed. Of course, all transactions are
>> terminated
>> >>> in
>> >>> OpenSIPS - either by received replies, either by a timeout (if no
>> reply
>> >>> received).
>> >>>
>> >>> If you want to generate the STOP event at BYE request time (versus
>> >>> BYE
>> >>> reply time), you can manually do it from script via the acc function
>> >>> acc_db_request() (instead of setting the acc flag and letting the acc
>> >>> module to generate automatically the event) - the generate event is
>> >>> the
>> >>> same. See:
>> >>>
>> >>> http://www.opensips.org/html/docs/modules/1.9.x/acc.html#id294346
>> >>>
>> >>> Regards,
>> >>>
>> >>> Bogdan-Andrei Iancu
>> >>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>> >>>
>> >>>
>> >>> On 04/30/2013 08:00 AM, qasimak...@gmail.com wrote:
>> >>>
>> >>> I have tried this scenario. Still if the User B is behind a NAT or
>> >>> is
>> >>> unreachable the opensips generates the BYE with retransmitted BYE's
>> >>> and
>> >>> the
>> >>> dialog is closed but there is no response to BYE received from that
>> user
>> >>> hence no radius acct request.
>> >>>
>> >>> Regards,
>> >>> Qasim
>> >>>
>> >>>
>> >>> On Mon, Apr 29, 2013 at 8:36 PM, Muhammad Shahzad
>> >>> wrote:
>> >>>
>> Per my understanding, accounting event is sent when BYE completes,
>> whether if destination replies with 200 OK or BYE re-transmission
>> times
>> out
>> and opensips responds with 408 Request timeout. In each case SIP
>> response
>> code is set appropriately and you should use stop time as accounting
>> end
>> time rather then the time your receive account stop request on
>> radius
>> (they
>> both may differ, e.g. under high load scenarios).
>>
>> Thank you.
>>
>>
>>
>> On Mon, Apr 29, 2013 at 3:27 PM, qasimak...@gmail.com <
>> qasimak...@gmail.com> wrote:
>>
>> >Hi,
>> >
>> > I wanted to confirm if radius accounting requests are generated on
>> > a
>> > successful transaction or it can be generated on a receive
Re: [OpenSIPS-Users] Registrar not saving received from Path header
I am currently using version 1.8.2 of opensips. I am using this code on
the registrar server, save("location","p0v"), when the user is
authenticated. The user is behind a firewall. The register request is
first sent to the sip proxy which forwards it to the registrar server.
The sip proxy adds the Path header with the source IP/Port of the
Register request. From the documentation it sounds like the save()
function should take the "received" parameter from the Path header and
store it in the "received" column of the location table. When I look at
the location table it contains the IP address and port of the SIP proxy
so when I try to locate the user, they are being sent to the SIP proxy
and the call fails. Is my understanding correct? What is the best
approach for this, UAC --> firewall --> P1 --> REG.
Thanks
Nathaniel
On 5/4/13 4:26 AM, Bogdan-Andrei Iancu wrote:
Hello Nathaniel,
See
http://www.opensips.org/html/docs/modules/1.9.x/registrar.html#id248705 -
this controls the PATH support in REGISTRAR module.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05/04/2013 01:31 AM, Nathaniel L Keeling III wrote:
Hello,
I sent an earlier post concerning NATed registrations not being able
to locate from the lookup() function when the registration request is
sent from a opensips proxy server to an opensips registration server
and from my research it looks like I should be using the Path header
with the received parameter set. Doing this, the Register request is
sent to the registrar proxy server with a Path header, the user is
successfully authorized and saved in the location table but when I
look at the location table entry, the received column either does not
contain a value or it contains the wrong value. Here is the Register
request sent from the proxy to the registrar server and the output
from the location table.
REGISTER sip:my-sip-domain.com;transport=tcp SIP/2.0.
Call-ID: 541d070a84f74ca6f61f68732d063d35@0:0:0:0:0:0:0:0.
CSeq: 2 REGISTER.
From: "Nathaniel L Keeling III"
;tag=cbe17bd3.
To: "Nathaniel L Keeling III" .
Max-Forwards: 68.
User-Agent: Jitsi2.0.4506.10553Mac OS X.
Expires: 600.
Contact: "Nathaniel L Keeling III"
;expires=600.
Via: SIP/2.0/UDP
xxx.xxx.110.38:5060;branch=z9hG4bK-383637-fa379c63d9b82d3f671742fe537882a1;i=04.
Via: SIP/2.0/TCP
192.168.43.237:65457;received=208.54.44.148;branch=z9hG4bK-383637-fa379c63d9b82d3f671742fe537882a1.
Authorization: Digest
username="nkeeling3",realm="mydomain2.com",nonce="5184345b003b08c40d29a091fb53e6cb83c3961c1dbb",uri="sip:my-sip-domain.com;transport=tcp",response="987edb51f504ff56c7ba840d594c4bb1".
Content-Length: 0.
Path:
.
Path: .
id | username |domain |
contact | received | path
| expires | q | callid | cseq |
last_modified| flags | cflags | user_agent |
socket | methods | sip_instance
--+---+---++-+--+-++--+--+-+---++-+-+-+--
1555 | nkeeling3 | mydomain2.com |
sip:nkeeling3@192.168.43.237:65420;transport=tcp;registering_acc=mydomain2_com
| sip:xxx.xxx.110.38:5060 | | 2013-05-03 17:08:03 | -1 |
869321ee55e10970ff139673909ab626@0:0:0:0:0:0:0:0 | 10 | 2013-05-03
16:58:03 | 0 | 1024 | Jitsi2.0.4506.10553Mac OS X |
udp:xxx.xxx.110.48:5060 | |
1556 | nkeeling3 | mydomain2.com |
sip:nkeeling3@192.168.43.237:65457;transport=tcp;registering_acc=mydomain2_com
| sip:xxx.xxx.110.38:5060 | | 2013-05-03 17:13:42 | -1 |
541d070a84f74ca6f61f68732d063d35@0:0:0:0:0:0:0:0 |2 | 2013-05-03
17:03:42 | 0 | 1024 | Jitsi2.0.4506.10553Mac OS X |
udp:xxx.xxx.110.48:5060 | |
Thanks
Nathaniel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
