date:20160123

Re: [OpenSIPS-Users] User location replication

2016-01-23 Thread sevpal

When you do the mongo query of the location table, the socket field corresponds 
to the transport being used by the UAS. That can be used along with the 
$branch(q) to construct the branch. 

From: Tito Cumpen 
Sent: Friday, January 22, 2016 6:46 PM
To: OpenSIPS users mailling list 
Subject: [OpenSIPS-Users] User location replication

Group, 

At the previous opensips summit I heard mention of a new module that could aid 
with user replication to other servers. I am currently using a dns srv aware 
client and I'd like to know how this would work with active-active scenarios? 
Say a user exist in several servers. I am currently using a rabbit 
solution to keep track of where a user is registered and a mongo query add the 
branch and fork calls to other servers. Is there another solution to this? I am 
hitting a roadblock due to the necessity to change priority of a branch based 
on the callee transport type. This requirement is one that is enforced by 
rtpengine since it cannot deal with parallel branches that require different 
media attributes. My issue is if the user exist in another server how do I 
prioritize based on transport without knowing?

Thanks,
Tito

___
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] opensips regster issue

2016-01-23 Thread MichaelLeung


i fix the problem myself

just add your domain name to opensips.cfg
like:
 listen:udp:yourdoamdin.com:5060


On 01/23/2016 02:59 PM, MichaelLeung wrote:

any reply ?

On 01/23/2016 01:17 AM, MichaelLeung wrote:

Hi team

my opensips server can accept regster request using IP address from 
client , but will not accept with domain name.


there is the output log from debug 4

please help me to find out what cause  the problem , thanks

---
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_msg: SIP Request:
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_msg:  method:  
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_msg:  uri: 
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_msg:  version: 
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: flags=2
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_via_param: found param type 232,  = 
; state=6
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_via_param: found param type 235,  = ; state=17
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_via: end of header reached, state=5
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: via found, flags=2
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: this is the first via
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:receive_msg: After parse_msg...
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:receive_msg: preparing to run routing scripts...
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: flags=100
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_to: end of header reached, state=9
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_to: display={}, ruri={sip:1...@sip2.x.eu.org}
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:get_hdr_field:  [30]; uri=[sip:1...@sip2.x.eu.org]
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:get_hdr_field: to body [sip:1...@sip2.x.eu.org#015#012]
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:get_hdr_field: cseq : <30> 
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:maxfwd:is_maxfwd_present: value = 70
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:uri:has_totag: no totag
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: flags=78
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:tm:t_lookup_request: start searching: hash=920, isACK=0
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:tm:matching_3261: RFC3261 transaction matching failed
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:tm:t_lookup_request: no transaction found
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: flags=200
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:get_hdr_field: found end of header
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:rr:find_first_route: No Route headers found
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:rr:loose_route: There is no Route HF
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if host==us: 20==13 &&  
[sip2.x.eu.org] == [192.168.29.57]
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if host==us: 20==7 &&  
[sip2.x.eu.org] == [9.9.9.9]
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if host==us: 20==13 &&  
[sip2.x.eu.org] == [192.168.29.57]
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if host==us: 20==7 &&  
[sip2.x.eu.org] == [9.9.9.9]
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:check_self: host != me
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: flags=
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:tm:t_newtran: transaction on entrance=(nil)
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers: flags=
Jan 23 01:09:52 ali /opt/opensips/sbin/opensips[30344]: 
DBG:core:parse_headers:

[OpenSIPS-Users] Dispatcher with multiple interface

2016-01-23 Thread Satish Patel

I have following scenario 

[client]-Public-IP--[dispatcher]--LAN-IP--[proxy]

Dispatcher has multi home interface, public and private, when client send 
request to dispatcher public Interface then dispatcher should use private LAN 
IP to send that request to Proxy can dispatcher do that? 

Current dispatcher only using public IP to send request to proxy. I wants it 
use LAN IP to forward request. 

How that will possible ?



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSIPS on Amazon EC2

2016-01-23 Thread Jason Bedward

Hi,

I have previously had this working without issue. But for some reason now I
can not get it to work. I have set advertised IP, and Opensips is showing
that its waiting for traffic on that IP.

But when traiffic comes in OpenSIPS does not process it. I have used ngrep
to monitor. OpenSIPS itself seems to be working as I have a keep alive
which was talking to a freeswitch server that was working.

I have taken the same config and put it on Digital Ocean and it worked
first time.

Also I have tried version 1.71, 1.8, 2 all with same result. Anyone having
success that could give advice?

Thanks
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips not processing replies from callee

2016-01-23 Thread Husnain Taseer

Dear Users,
I am trying to do the performance test of our newly build opensips proxy
server using sipp, but facing many issues. I am also using Freeradius for
AAA operations. When I send calls with 1 CPS everything works perfect, but
as I increase the CPS opensips stop processing replies from callee. At a
rate of 5 cps the call flow turns into:

 sipp (caller)  Opensips --- sipp (Callee)

  ---INVITE>

RADIUS Auth

---INVITE->

<100 Trying--

<---180 Ringing--

<--200 OK-

---INVITE>

---INVITE>

---INVITE>


Callee is sending back proper responses which are being processed at low
CPS but on high CPS opensips even not printing the logs of on_reply_route
section, and as shown in the trace opensips keep sending INVITE of the same
call-id even responses have been received. I have tried different opensips
versions 2.1.1, 2.1.2 and 1.11.1-tls, but same issue is there for all of
these versions. On 200 OK Opensips is also triggering accounting event on
FreeRadius server, is it possible that FreeRadius is creating problem on
high CPS ?

With Version 2.1.1 and 2.1.2 I am also getting timer warning and opensips
accounting stop event error in the logs:

*Jan 22 12:41:29 66-226-76-150 ./opensips[19633]:
WARNING:core:utimer_ticker: utimer task  already schedualed for
116920 ms (now 117020 ms), it may overlap..*
*Jan 22 12:41:29 66-226-76-150 ./opensips[19633]:
WARNING:core:utimer_ticker: utimer task  already schedualed for
117020 ms (now 117120 ms), it may overlap..*
*Jan 22 12:41:29 66-226-76-150 ./opensips[19633]:
WARNING:core:utimer_ticker: utimer task  already schedualed for
117120 ms (now 117220 ms), it may overlap..*
*Jan 22 12:41:29 66-226-76-150 ./opensips[19705]: rc_send_server: no reply
from RADIUS server localhost:1813*
*Jan 22 12:41:29 66-226-76-150 ./opensips[19705]:
ERROR:acc:acc_aaa_request: Radius accounting request failed for status:
'Stop' Call-Id: '1-23993@104.237.143.243 <1-23993@104.237.143.243>'*
*Jan 22 12:41:29 66-226-76-150 ./opensips[19705]:
WARNING:core:handle_timer_job: utimer job  has a 11729 us
delay in execution*
*Jan 22 12:41:29 66-226-76-150 ./opensips[19653]:
WARNING:core:handle_timer_job: timer job  has a 2688 us delay
in execution*

But Radius Accounting stop event is nothing to do with 200OK, because on
200 OK accounting start event is triggered on the RADIUS server which is
properly triggered.
I am using 10 opensips children process and sending 100 calls with 10 CPS
and duration of all the calls is 10 sec. Currently we are stuck there and
not able to move this machine into production please advice how to get rid
of this issue.

We also have exactly same revision of Opensips and RADIUS code running
perfectly in production, but on this new server we are facing this issue.

Regards,
Husnain Taseer
VoIP Developer
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] presence xpidf

2016-01-23 Thread Stas Kobzar

Hi Bogdan,

I can confirm that Polycom still use xpidf with the latest firmware ver. 5.

I think Digium phones also use xpidf. Can not say for other vendors.
Looks like xpidf is supported by Asterisk, FreeSWITCH.
Quick google search makes me believe that pjsip, reSIProcate and linphone
(osip) have xpidf support.

You are right, the draft is quite old, and I can not find any update.
But xpidf is still there.

Thank you,
Stas


On Fri, Jan 22, 2016 at 8:19 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Stas,
>
> While looking around for this xpidf I found this:
> http://opensips.org/pipermail/users/2010-April/012336.html
>
> So, what is the story with this xpdif ? is it still in use ? was it
> replaced by pidf+xml ? as I see it died as draft.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 13.01.2016 18:47, Stas Kobzar wrote:
>
> Hi Bogdan,
>
> I do not think the DOCTYPE is the problem here. What I see is that when I
> use MI to publish this application/xpidf doc, OpenSIPS does not want to
> parse the document, and if I understand correct, this is because this type
> of document does not have  XML branch.
>
> You are right, about end-to-end, and if I configure OpenSIPS just to relay
> SUBSCRIBE/NOTIFY, it should work fine.
> But I want use OpenSIPS to be in the middle because I have a logic in my
> application when it is me who change the status (for example with
> web-interface)
>
> So basically my question is, is it going to be supported by OpenSIPS
> (application/xpidf)? Or as you mentioned, it is basically the work for UA
> and it is not supposed to be in OpenSIPS?
>
> Thank you,
>
>
> On Wed, Jan 13, 2016 at 7:56 AM, Bogdan-Andrei Iancu <
> bog...@opensips.org> wrote:
>
>> Hi Stas,
>>
>> You say you see the DOCTYPE line in NOTIFY packets and this is supported
>> by OpenSIPS ?
>>
>> Now, on Polycom extension - if it is something end-2-end, it means it
>> does not require a presence server and everything should be between end
>> points by using SUBSCRIBE and NOTIFY (no PUBLISH, as this is specific to
>> the presence agent/server model). Am I wrong with this ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 12.01.2016 17:10, Stas Kobzar wrote:
>>
>> Hello Bogdan,
>>
>> Thank you for your response.
>> The DOCTYPE within XML is seems to be Microsoft presence format:
>> https://msdn.microsoft.com/en-ca/library/cc246193.aspx
>>
>> I am not sure if it can be used with PUBLISH though. For now I saw it
>> only in NOTIFY packets.
>>
>> Polycom UA is using this type of presence for end-to-end presence between
>> phones.
>> I would like to publish this with MI to change presence status on Polycom
>> phones.
>>
>> Thank you,
>> Stas
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jan 11, 2016 at 4:59 AM, Bogdan-Andrei Iancu <
>> bog...@opensips.org> wrote:
>>
>>> Hi Stas,
>>>
>>> I checked with couple of SIP UACs and I found none using the "DOCTYPE"
>>> line the published presence XML. So, I guess you should simply drop such a
>>> line in your testing.
>>>
>>> The "tuple" node is replacing your "atom" node (at least this is what I
>>> noticed while trying other UACs). Here is an example of a PUBLISH xml
>>> generated by Zoiper:
>>>
>>> 
>>> >> "sip:bog...@opensips.org;transport=UDP"
>>> >
>>> 
>>> open
>>> 
>>> Busy
>>> 
>>> 
>>>
>>> In regards to the crash, even if the XML is not properly formated, it
>>> should not crash - can you send me the actual MI command + content to try
>>> to reproduce the crash and have it fixed ?
>>>
>>> Best regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>> On 04.01.2016 18:49, Stas Kobzar wrote:
>>>
>>> Hello all and Happy New Year!
>>>
>>> I have a problem with publishing application/xpidf+xml (Xpidf) presence
>>> info with OpenSIPS mi (ver11).
>>> It seems like it is not supported.
>>>
>>> The xpidf xml body is something like this:
>>>
>>> 
>>> >> "xpidf.dtd">
>>> 
>>>   >> />
>>>   
>>> >> priority="0.80">
>>>   
>>>   
>>> 
>>>   
>>> 
>>>
>>> After browsing around the source I think there are two problems:
>>> 1. (in modules/pua/add_events.c:pres_process_body) function from
>>> libxml2 xmlParseMemory returns NULL when finds the line >> PUBLIC "-//IETF//DTD RFC XPIDF 1.0//EN" "xpidf.dtd">
>>>
>>> 2. Another problem: when I remove the line above from body there is a
>>> call to another function that is looking for "" node in xml (in
>>> modules/pua/add_events.c:pres_process_body):
>>> node= xmlDocGetNodeByName(doc, "tuple", NULL);
>>>
>>> But there is no "tuple" in xpidf document. So it returns error.
>>>
>>> 3. As an experiment, I added "" inside my presence body and it
>>> crashed OpenSIPS with:
>>>

[OpenSIPS-Users] Fragmentation issue

2016-01-23 Thread Jai Rangi

My Previous message got high jacked due to Subject. Posting is again as a
new thread.

Hello,

I have two opensip servers, exactly same configuration, but one is acting
different. This is the call  flow.
Origination -- Invite> Opensips
Origination < 100 Trying -- Opensips
 ---Opensips invite --> End user
(freeswitch)
Opensips <--- 100 trying --
Freeswitch
Opensips <-- 183 Ringing --
Freeswitch
Keeps waiting and never forward 183 back to Origination.

While 2nd opensips works just fine/

MTU is 1500 on both.
Working Server versions
Centos 5.2, Openisps 11-2

Not working, version (Different OS, same version of Opensips)
Cent OS 5.4, Opensips 11-2

Below is the full trace. Any hint to fix this will big help. I am
suspecting fragmented packet size in 183 Session Progress, but not sure how
to fix it. If the packet is not fragmented all works fine.
Did some more testing, if I route the call to another IP, that works
fine. So something very specific to this IP only.

This is original trace, ALL IPs has been modified for security.

 15.43.72.36:5060 -> 29.16.115.170:5060
INVITE sip:+130 at domain.opensips.company.com
:5060;user=phone;transport=UDP;maddr=29.16.115.170
SIP/2.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: 
>*;screen=yes;party=calling;privacy=off.
*f: :5060
;user=phone>;tag=-45026-1a697ef-67d2935e-1a697ef.
t: :5060;user=phone>.
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 15.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP 18 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=fmtp:18 annexb=no.

#
U 29.16.115.170:5060 -> 15.43.72.36:5060
SIP/2.0 100 Giving a try.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
f: :5060
;user=phone>;tag=-45026-1a697ef-67d2935e-1a697ef.
t: :5060;user=phone>.
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Server: Opensips SIP Gateway.
Content-Length: 0.
.

#
U 29.16.115.170:5060 -> 28.3.8.20:5060
INVITE sip:130 at 28.3.8.20
:5060;user=phone;transport=UDP
SIP/2.0.
Record-Route:
.
Via: SIP/2.0/UDP 29.16.115.170:5060;branch=z9hG4bK3a79.ead0d7c5.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: 
>*;screen=yes;party=calling;privacy=off.
*f: :5060
;user=phone>;tag=-45026-1a697ef-67d2935e-1a697ef.
t: :5060;user=phone>.
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 14.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP

[OpenSIPS-Users] Opensips Packet Size Issue

2016-01-23 Thread Jai Rangi

Hello,

I have two opensip servers, exactly same configuration, but one is acting
different. This is the call  flow.
Origination -- Invite> Opensips
Origination < 100 Trying -- Opensips
 ---Opensips invite --> End user
(freeswitch)
Opensips <--- 100 trying --
Freeswitch
Opensips <-- 183 Ringing --
Freeswitch
Keeps waiting and never forward 183 back to Origination.

While 2nd opensips works just fine/

MTU is 1500 on both.
Working Server versions
Centos 5.2, Openisps 11-2

Not working, version (Different OS, same version of Opensips)
Cent OS 5.4, Opensips 11-2

Below is the full trace. Any hint to fix this will big help. I am
suspecting fragmented packet size in 183 Session Progress, but not sure how
to fix it. If the packet is not fragmented all works fine.

This is original trace, ALL IPs has been modified for security.

 15.43.72.36:5060 -> 29.16.115.170:5060
INVITE 
sip:+1304...@domain.opensips.company.com:5060;user=phone;transport=UDP;maddr=29.16.115.170
SIP/2.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: ;screen=yes;party=calling;privacy=off.
f: ;tag=-45026-1a697ef-67d2935e-1a697ef.
t: .
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 15.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP 18 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=fmtp:18 annexb=no.

#
U 29.16.115.170:5060 -> 15.43.72.36:5060
SIP/2.0 100 Giving a try.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
f: ;tag=-45026-1a697ef-67d2935e-1a697ef.
t: .
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Server: Opensips SIP Gateway.
Content-Length: 0.
.

#
U 29.16.115.170:5060 -> 28.3.8.20:5060
INVITE sip:130@28.3.8.20:5060;user=phone;transport=UDP SIP/2.0.
Record-Route:
.
Via: SIP/2.0/UDP 29.16.115.170:5060;branch=z9hG4bK3a79.ead0d7c5.0.
v: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Record-Route: .
Remote-Party-ID: ;screen=yes;party=calling;privacy=off.
f: ;tag=-45026-1a697ef-67d2935e-1a697ef.
t: .
i: b3338bd0185eadc713c41a697ef72c17e921839f4f01a344bb8-0091-7406.
CSeq: 1 INVITE.
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK.
v: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
v: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Max-Forwards: 14.
m: .
k: 100rel, resource-priority, replaces.
c: application/sdp.
l: 235.
Record-Route: .
.
v=0.
o=PVG 1453494628460 1453494628460 IN IP4 199.173.133.17.
s=-.
p=+1 613555.
c=IN IP4 199.173.133.17.
t=0 0.
m=audio 34552 RTP/AVP 18 0 8 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=fmtp:18 annexb=no.

#
U 28.3.8.20:5060 -> 29.16.115.170:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 29.16.115.170:5060;branch=z9hG4bK3a79.ead0d7c5.0.
Via: SIP/2.0/UDP 15.43.72.36:5060
;branch=z9hG4bKa83557bc149a92c4dd2e82551235a4d3.35f93e16.
Via: SIP/2.0/UDP 52.88.1.5:5060
;branch=z9hG4bK0cba239efe292bb148db0d60f1938f42.4937234e;received=52.88.1.5.
Via: SIP/2.0/UDP
IRW6:5060;maddr=19.73.4.24;branch=z9hG4bK-1a697ef-72c17e92-7809c98f;received=19.73.94.24.
Record-Route:
.
Record-Route: .
Record-Route: .
From: ;tag=-45026-1a697ef-67d2935e-1a697ef.
To:

Re: [OpenSIPS-Users] User location replication

Re: [OpenSIPS-Users] opensips regster issue

[OpenSIPS-Users] Dispatcher with multiple interface

[OpenSIPS-Users] OpenSIPS on Amazon EC2

[OpenSIPS-Users] Opensips not processing replies from callee

Re: [OpenSIPS-Users] presence xpidf

[OpenSIPS-Users] Fragmentation issue

[OpenSIPS-Users] Opensips Packet Size Issue

8 matches

Site Navigation

Mail list logo

Footer information