[Spce-user] retries of INVITES for session timers
Matthew Ogden
matthew at tenacit.net
Fri Apr 5 08:54:00 EDT 2013
HI Ivan,
Sorry I have already deleted it (and our server only keeps it for 1 day).
But as mentioned, the issue is SEMS no reINVITING after client sends 100.
This is the issue I’m trying to investigate, and no one out there seems
bothered that SEMS is broken.
SEMS should do this:
Client sends initial authenticated INVITE
SEMS Accept initial authenticated INVITE
SEMS Wait for timer period
SEMS Send reinvite
Client sends initial 100 – trying
Client sends initial 200 – OK
SEMS Wait for timer period
SEMS Send reinvite
Client sends initial 100 – trying
---No 200???
SEMS Send reinvite RETRY (BUT this is not happening… after a 100 is
received, no subsequent retry occurs. In my opionion SEMS is broken? But I
don’t know how to prove/check this)
Client sends initial 100 – trying
Client sends initial 200 – OK
Regards
*From:* Ivan Milivojevic [mailto:edesibe at googlemail.com]
*Sent:* 05 April 2013 10:40 AM
*To:* Matthew Ogden
*Subject:* Re: [Spce-user] retries of INVITES for session timers
hi matthew,
can you send me a screenshot of wireshark trace of that session
regards
i
On Fri, Apr 5, 2013 at 10:28 AM, Matthew Ogden <matthew at tenacit.net> wrote:
Sorry, Ivan,
I mean I have already looked at the info in wireshark, we packet capture
everything.
The wireshark info, provided nothing additional. The logs represent what
had happened correctly. SEMS kills the call because of a timeout.
That timeout is wrong though, because it was SEMS responsibility to retry
the reINVITE. But for some reason, after a client sends a 100, SEMS decides
that if it doesn’t receive a 200, it wont retry.
In other words, once a 100 is received for a reinvite, the state that SEMS
puts itself in, is simply “wait longer until timeout”, instead, it should
retry after a few seconds if no reply has been received, but once a 100 is
received, it does not do this.
*From:* Ivan Milivojevic [mailto:edesibe at googlemail.com]
*Sent:* 05 April 2013 10:25 AM
*To:* Matthew Ogden
*Subject:* Re: [Spce-user] retries of INVITES for session timers
follow
1.tshark -D
2.then tshark -i <any_number> ....
at my server
tshark -D
1. eth0
2. dummy0
3. eth1
4. any (Pseudo-device that captures on all interfaces)
in my case is:
tshark -i 4 #### to include all interface
regards
i
On Fri, Apr 5, 2013 at 10:17 AM, Matthew Ogden <matthew at tenacit.net> wrote:
Yes, I have tshark info, it provides the same info, but not showing proxy
to LB, and it appears SEMS is the cause.
But to me it seems faulty that SEMS does retry re-INVITE if there is no
200, but the was a 100 received from client. (It stops after a 100 was
received), but then times call out anyway.
*From:* Ivan Milivojevic [mailto:edesibe at googlemail.com]
*Sent:* 05 April 2013 10:15 AM
*To:* Matthew Ogden
*Subject:* Re: [Spce-user] retries of INVITES for session timers
i have a problem with sending email to the list,
:)
so,i just wanted to help
you should start tcpdump/tshark to see the all messages
regards
i
On Fri, Apr 5, 2013 at 10:04 AM, Ivan Milivojevic <edesibe at googlemail.com>
wrote:
also,
you can see the rtp.log
i assume there is somwthing like:
Closing call branch due to timeout
regards
i
On Fri, Apr 5, 2013 at 9:57 AM, Ivan Milivojevic <edesibe at googlemail.com>
wrote:
hi matthew,
based on proxy-log,
bye from sems
Apr 3 14:30:33 spce /usr/sbin/kamailio[20175]: INFO: <script>: New request
- M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080(127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20175]: INFO: <script>: Stop
mediaproxy for all branches - M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
proxy relay BYE to lb
Apr 3 14:30:33 spce /usr/sbin/kamailio[20175]: INFO: <script>: Relaying
request - M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080(127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
*IP=udp:**127.0.0.1:5080 - sems ip and port*
LB
bye from sems
Apr 3 14:30:33 spce /usr/sbin/kamailio[12348]: INFO: <script>: New request
- M=BYE R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
...
bye from proxy(sems is also the origin)
Apr 3 14:30:33 spce /usr/sbin/kamailio[12355]: INFO: <script>: New request
- M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
*so,i would say that sems sends BYE*
But I really struggle to understand which side has initiated the BYE. I
know a call goes - device - LB - Proxy - B2BUA - Proxy - LB - Peer
### a normal call should go through - device - LB - PROXY - B2BUA - LB -
PEER
### this call went different path because SEMS sends 2x BYE
messages,first B2BUA->LB->PEER
and second, B2BUA->PROXY->LB->device
you could start tcpdump or tshark to see the whole session.
regards
ivan
On Thu, Apr 4, 2013 at 8:36 PM, Matthew Ogden <matthew at tenacit.net> wrote:
Hi All,
Does anyone else have any ideas?
I know that Andrew is often tied up for a week at a time before he can
reply. Maybe some of you have some suggestions, ideas, that he can also
read through, or that I can try, that would add value to this issue.
Regards
*From:* Matthew Ogden [mailto:matthew at tenacit.net]
*Sent:* 03 April 2013 07:11 PM
*To:* 'spce-user at lists.sipwise.com'
*Cc:* 'Andrew Pogrebennyk'
*Subject:* FW: [Spce-user] retries of INVITES for session timers
HI Andrew,
(I wasn’t sure if I would get time to convert this And catch Andrew), but
here is the ongoing of this thread – converted to private info)
Sorry for coming back to you so long apart, I dont want to include the list
on this yet.
Am I correct in understanding here (Asterisk box iniated this call from
<ClientPublicIP>) that at 14:28, the call was routed using peer
<SipPeerIP?>:
But I really struggle to understand which side has initiated the BYE. I
know a call goes - device - LB - Proxy - B2BUA - Proxy - LB - Peer
I once again suspect the issue is this:
Apr 3 14:28:03 spce /usr/sbin/kamailio[20180]: INFO: <script>: NAT-Reply -
S=100 - Trying F=sip:031<called#>@<sipDomain:5060 T=sip:WS001A001@<SipDomain>
IP=127.0.0.1:5080 (127.0.0.1:5060) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Does this mean that the device at ClientPublicIP, never sent the 200 OK?
There should have been a S-200 just after that. To me it appears that the
problem must be that if a 100 Trying is received, no subsequent RE-INVITES
will occur from SPCE (Assuming SEMS is resposinble for this?)
I have no idea how to look up if thats normal behaviour for SEMS, but
perhaps you can tell me? Also can you confirm it was indeed the device,
that was at fault from the log ?
Load balancer
Apr 3 14:28:03 spce /usr/sbin/kamailio[12350]: INFO: <script>: New request
- M=INVITE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[12350]: INFO: <script>: Mask local
B2BUA contact - M=INVITE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[12350]: INFO: <script>: New request
- M=INVITE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[12350]: INFO: <script>: Perform
loose-routing, du='<null>' - M=INVITE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[12350]: INFO: <script>: Relaying
request, du='<null>', fs='udp:<SPCE_PublicIP>:5060' - M=INVITE
R=sip:WS001A001@<ClientPublicIP>:5060 F=sip:031<called#>@<sipDomain>:5060
T=sip:WS001A001@<sipDomain>
IP=udp:127.0.0.1:5062ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:28:08 spce /usr/sbin/kamailio[12348]: INFO: <script>: New request
- M=UPDATE R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:28:08 spce /usr/sbin/kamailio[12348]: INFO: <script>: Mask local
B2BUA contact - M=UPDATE R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:28:08 spce /usr/sbin/kamailio[12348]: INFO: <script>: Perform
loose-routing, du='<null>' - M=UPDATE
R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:28:08 spce /usr/sbin/kamailio[12348]: INFO: <script>: Relaying
request, du='<null>', fs='udp:<SPCE_PublicIP>:5060' - M=UPDATE
R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:28:08 spce /usr/sbin/kamailio[12340]: INFO: <script>: Reply from
Outbound - S=200 - OK F=sip:2721<CalleR#>@<sipDomain>
T=sip:031<called#>@<sipDomain>:5060 IP=udp:<SIPPeerIP>:5060
ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:28:08 spce /usr/sbin/kamailio[12340]: INFO: <script>: Sending
reply, fs='udp:127.0.0.1:5060' - S=200 - OK F=sip:2721<CalleR#>@<sipDomain>
T=sip:031<called#>@<sipDomain>:5060 IP=udp:<SIPPeerIP>:5060
ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:30:33 spce /usr/sbin/kamailio[12348]: INFO: <script>: New request
- M=BYE R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:30:33 spce /usr/sbin/kamailio[12348]: INFO: <script>: Perform
loose-routing, du='<null>' - M=BYE
R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:30:33 spce /usr/sbin/kamailio[12348]: INFO: <script>: Relaying
request, du='<null>', fs='udp:<SPCE_PublicIP>:5060' - M=BYE
R=sip:031<called#>@<SIPPeerIP>:5060;transport=udp
F=sip:2721<CalleR#>@<sipDomain> T=sip:031<called#>@<sipDomain>:5060 IP=udp:
127.0.0.1:5080 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:30:33 spce /usr/sbin/kamailio[12354]: INFO: <script>: New request
- M=ACK R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12354]: INFO: <script>: Mask local
B2BUA contact - M=ACK R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12354]: INFO: <script>: New request
- M=ACK R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12354]: INFO: <script>: Perform
loose-routing, du='<null>' - M=ACK R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12354]: INFO: <script>: Relaying
request, du='<null>', fs='udp:<SPCE_PublicIP>:5060' - M=ACK
R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12355]: INFO: <script>: New request
- M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12355]: INFO: <script>: New request
- M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12355]: INFO: <script>: Perform
loose-routing, du='<null>' - M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12355]: INFO: <script>: Relaying
request, du='<null>', fs='udp:<SPCE_PublicIP>:5060' - M=BYE
R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain> IP=udp:
127.0.0.1:5062 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12343]: INFO: <script>: Reply from
Outbound - S=200 - OK F=sip:2721<CalleR#>@<sipDomain>
T=sip:031<called#>@<sipDomain>:5060 IP=udp:<SIPPeerIP>:5060
ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:30:33 spce /usr/sbin/kamailio[12343]: INFO: <script>: Sending
reply, fs='udp:127.0.0.1:5060' - S=200 - OK F=sip:2721<CalleR#>@<sipDomain>
T=sip:031<called#>@<sipDomain>:5060 IP=udp:<SIPPeerIP>:5060
ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>_b2b-1
Apr 3 14:30:33 spce /usr/sbin/kamailio[12344]: INFO: <script>: Reply from
Outbound - S=200 - OK F=sip:031<called#>@<sipDomain>:5060
T=sip:WS001A001@<sipDomain>
IP=udp:<ClientPublicIP>:5060 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[12344]: INFO: <script>: Sending
reply, fs='udp:127.0.0.1:5060' - S=200 - OK
F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain>
IP=udp:<ClientPublicIP>:5060 ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Proxy:
Apr 3 14:25:38 spce /usr/sbin/kamailio[20178]: INFO: <script>: Relaying
request - M=ACK R=sip:127.0.0.1:5080 F=sip:WS001A001@<sipDomain>
T=sip:031<called#>@<sipDomain>:5060 IP=<ClientPublicIP>:5060 (127.0.0.1:5060)
ID=05f68e236804e86677f9cbff7afaf4b8@<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[20178]: INFO: <script>: New request
- M=INVITE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[20178]: INFO: <script>: Use
mediaproxy for forward direction for IPv4/IPv4 - M=INVITE
R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[20178]: INFO: <script>: Relaying
request - M=INVITE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:28:03 spce /usr/sbin/kamailio[20180]: INFO: <script>: NAT-Reply -
S=100 - Trying F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain>
IP=127.0.0.1:5080 (127.0.0.1:5060) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20176]: INFO: <script>: New request
- M=ACK R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20175]: INFO: <script>: New request
- M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20175]: INFO: <script>: Stop
mediaproxy for all branches - M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20176]: INFO: <script>: Relaying
request - M=ACK R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20175]: INFO: <script>: Relaying
request - M=BYE R=sip:WS001A001@<ClientPublicIP>:5060
F=sip:031<called#>@<sipDomain>:5060 T=sip:2721<CalleR#>@<sipDomain> IP=
127.0.0.1:5080 (127.0.0.1:5080) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20174]: INFO: <script>: NAT-Reply -
S=100 - Trying F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain>
IP=127.0.0.1:5080 (127.0.0.1:5060) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
Apr 3 14:30:33 spce /usr/sbin/kamailio[20177]: INFO: <script>: NAT-Reply -
S=200 - OK F=sip:031<called#>@<sipDomain>:5060 T=sip:WS001A001@<sipDomain>
IP=127.0.0.1:5080 (127.0.0.1:5060) ID=05f68e236804e86677f9cbff7afaf4b8@
<sipDomain>
On Tue, Feb 26, 2013 at 2:23 PM, Andrew Pogrebennyk <
apogrebennyk at sipwise.com> wrote:
On 02/26/2013 12:59 PM, Matthew Ogden wrote:
> Ok, so just to confirm:
>
> Current default settins:
> In the normal workins, a re-INVITE is sent, only once, and it normally has
> a 6s timeout to get back, (This setting increases that ay my discretion)
No, this is incorrect. a re-INVITE is sent once and then re-sent at the
500ms..1s..2s..4s points. If sems gets a 100 Trying back however, it
stops the retransmissions.
I have just checked your lb.log and looks like the re-INVITE was not
resent. Which leaves me wondering why it doesn't work for you like this.
Works on my test VM - there is a trace below. Could you send me the
trace from your server (ngrep -s0 -t -Wbyline -d any SIP port 5080) and
sems.log, after doing sems-stats -c "set_loglevel 3", so if this is a
sems problem we can report it to sems developers. Thanks.
#
U 2013/02/26 13:14:30.907027 127.0.0.1:5080 -> 127.0.0.1:5060
INVITE sip:29458701 at 10.10.8.25:41796;alias=192.168.51.1~16785~1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKAn9J9auH;rport.
From: <sip:0991003 at 192.168.51.210>;tag=0BDC0DDE-512CA7000006028C-B04DA700.
To: <sip:29458701 at 192.168.51.210>;tag=kgsCwYh0-BofYU1balBlUajMQN91IoFU.
CSeq: 12 INVITE.
Call-ID: s9QfC20n03xRSJxirjAwzkpHLt5tZ.x2_b2b-1.
Contact: <sip:127.0.0.1:5080>.
Route:
<sip:127.0.0.1;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes>,
<
sip:192.168.51.210;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes
>.
Supported: timer.
Session-Expires: 60.
Min-SE: 60.
Content-Type: application/sdp.
Content-Length: 284.
.
v=0.
o=- 3570869631 3570869632 IN IP4 192.168.51.210.
s=Blink 0.2.11 (Linux).
c=IN IP4 192.168.51.210.
t=0 0.
m=audio 30108 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=rtcp:50097.
a=sendonly.
a=oldmediaip:10.10.8.25.
a=direction:active.
#
U 2013/02/26 13:14:31.406203 127.0.0.1:5080 -> 127.0.0.1:5060
INVITE sip:29458701 at 10.10.8.25:41796;alias=192.168.51.1~16785~1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKAn9J9auH;rport.
From: <sip:0991003 at 192.168.51.210>;tag=0BDC0DDE-512CA7000006028C-B04DA700.
To: <sip:29458701 at 192.168.51.210>;tag=kgsCwYh0-BofYU1balBlUajMQN91IoFU.
CSeq: 12 INVITE.
Call-ID: s9QfC20n03xRSJxirjAwzkpHLt5tZ.x2_b2b-1.
Contact: <sip:127.0.0.1:5080>.
Route:
<sip:127.0.0.1;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes>,
<
sip:192.168.51.210;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes
>.
Supported: timer.
Session-Expires: 60.
Min-SE: 60.
Content-Type: application/sdp.
Content-Length: 284.
.
v=0.
o=- 3570869631 3570869632 IN IP4 192.168.51.210.
s=Blink 0.2.11 (Linux).
c=IN IP4 192.168.51.210.
t=0 0.
m=audio 30108 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=rtcp:50097.
a=sendonly.
a=oldmediaip:10.10.8.25.
a=direction:active.
#
U 2013/02/26 13:14:32.406204 127.0.0.1:5080 -> 127.0.0.1:5060
INVITE sip:29458701 at 10.10.8.25:41796;alias=192.168.51.1~16785~1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKAn9J9auH;rport.
From: <sip:0991003 at 192.168.51.210>;tag=0BDC0DDE-512CA7000006028C-B04DA700.
To: <sip:29458701 at 192.168.51.210>;tag=kgsCwYh0-BofYU1balBlUajMQN91IoFU.
CSeq: 12 INVITE.
Call-ID: s9QfC20n03xRSJxirjAwzkpHLt5tZ.x2_b2b-1.
Contact: <sip:127.0.0.1:5080>.
Route:
<sip:127.0.0.1;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes>,
<
sip:192.168.51.210;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes
>.
Supported: timer.
Session-Expires: 60.
Min-SE: 60.
Content-Type: application/sdp.
Content-Length: 284.
.
v=0.
o=- 3570869631 3570869632 IN IP4 192.168.51.210.
s=Blink 0.2.11 (Linux).
c=IN IP4 192.168.51.210.
t=0 0.
m=audio 30108 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=rtcp:50097.
a=sendonly.
a=oldmediaip:10.10.8.25.
a=direction:active.
#
U 2013/02/26 13:14:34.406147 127.0.0.1:5080 -> 127.0.0.1:5060
INVITE sip:29458701 at 10.10.8.25:41796;alias=192.168.51.1~16785~1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKAn9J9auH;rport.
From: <sip:0991003 at 192.168.51.210>;tag=0BDC0DDE-512CA7000006028C-B04DA700.
To: <sip:29458701 at 192.168.51.210>;tag=kgsCwYh0-BofYU1balBlUajMQN91IoFU.
CSeq: 12 INVITE.
Call-ID: s9QfC20n03xRSJxirjAwzkpHLt5tZ.x2_b2b-1.
Contact: <sip:127.0.0.1:5080>.
Route:
<sip:127.0.0.1;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes>,
<
sip:192.168.51.210;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes
>.
Supported: timer.
Session-Expires: 60.
Min-SE: 60.
Content-Type: application/sdp.
Content-Length: 284.
.
v=0.
o=- 3570869631 3570869632 IN IP4 192.168.51.210.
s=Blink 0.2.11 (Linux).
c=IN IP4 192.168.51.210.
t=0 0.
m=audio 30108 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=rtcp:50097.
a=sendonly.
a=oldmediaip:10.10.8.25.
a=direction:active.
#
U 2013/02/26 13:14:36.907011 127.0.0.1:5080 -> 127.0.0.1:5060
BYE sip:29458701 at 10.10.8.25:41796;alias=192.168.51.1~16785~1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKHdv4QaHY;rport.
From: <sip:0991003 at 192.168.51.210>;tag=0BDC0DDE-512CA7000006028C-B04DA700.
To: <sip:29458701 at 192.168.51.210>;tag=kgsCwYh0-BofYU1balBlUajMQN91IoFU.
CSeq: 13 BYE.
Call-ID: s9QfC20n03xRSJxirjAwzkpHLt5tZ.x2_b2b-1.
Route:
<sip:127.0.0.1;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes>,
<
sip:192.168.51.210;lr;r2=on;ftag=0BDC0DDE-512CA7000006028C-B04DA700;ngcplb=yes
>.
User-Agent: Sipwise NGCP Application Server.
Max-Forwards: 70.
Content-Length: 0.
.
_______________________________________________
Spce-user mailing list
Spce-user at lists.sipwise.com
http://lists.sipwise.com/listinfo/spce-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130405/b1b178aa/attachment-0001.html>
More information about the Spce-user
mailing list