No, A is not on hold. Placing on hold requires a user action. Unless the
user of A placed it on hold, A is not on hold. Anything done by B doesn't
affect A hold status.
_
Roman Shpount
On Thu, Sep 7, 2023 at 8:38 AM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.su
, B should
respond with a=inactive, since B is on hold.
_
Roman Shpount
On Thu, Sep 7, 2023 at 6:55 AM Sundbaum Per-Johan (Telenor Sverige AB) <
per-johan.sundb...@telenor.se> wrote:
> Hi !
>
> A question that I hope is simple for some helpful person to answer:
>
&
st Regards,
_____
Roman Shpount
On Tue, Aug 29, 2023 at 12:00 PM wrote:
> The dilemma I have is a UAC (service provider) sends an INVITE with
> transport=tls in the Request header as well as in the Contact header, using
> the SIP: URI scheme (not SIPS:).
>
>
>
> The UAS (an SBC) r
No, they do not.
_
Roman Shpount
On Mon, Apr 10, 2023 at 12:25 PM Arun T wrote:
> Thanks RFC talks about the non-reliable transport (UDP) what about
> reliable transport (TCP). Don’t UE/NW retransmit?
>
> On Mon, 10 Apr 2023 at 7:12 PM, Roman Shpount wrote:
>
>&g
Please take a look at hhttps://www.rfc-editor.org/rfc/rfc3261#section-17
_
Roman Shpount
On Mon, Apr 10, 2023 at 9:20 AM Arun T wrote:
> Hi All,
>
> Can any one share the spec./RFC which has information that SIP messages can
> be re-transmitted if no response is receiv
o
decipher the reasoning behind each signaling scenario.
So, YMMV
_____
Roman Shpount
On Mon, Oct 10, 2022 at 10:17 PM Dale R. Worley wrote:
> Ranjit Avasarala writes:
> > Another way to check is the SDP. for hold music, the media attribute
> will
> > be sendonly. where
.
For a generic solution, you need to use a VAD algorithm to differentiate
between voice vs. silence vs. hold music. You can look at
https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/common_audio/vad/
for reference.
_
Roman Shpount
On Thu, Sep 22, 2022 at 10:56
This is why the general answer "it depends".
I hope it helps,
_
Roman Shpount
On Mon, Sep 7, 2020 at 2:11 AM Shaun Stokes wrote:
> Hi,
>
> We've been struggling with some of the interpretation used in RFC 3261
> section 14.2 which has created a conflict between the so
. As a result, SIP signaling flow goes through SIP application server, but
media goes direct between SIP end points 1 and 2.
Regards,
_
Roman Shpount
On Tue, Apr 23, 2019 at 5:13 PM Alex Balashov
wrote:
> Paul,
>
> Why can’t it do that with an offer in the initi
ACK to 200 OK should be sent based on the route set, not VIA.
Regards,
_
Roman Shpount
On Sun, Feb 10, 2019 at 7:48 PM David Cunningham
wrote:
> Hello,
>
> Could someone please confirm the correct routing of an ACK?
> A device receives the following 200 OK. Should the
it is probably better to use SIPS or avoid
firewalls. Firewall and router SIP handling is almost universally broken
and should be turned of, if SIP usage is expected.
_
Roman Shpount
On Wed, Jan 2, 2019 at 6:32 PM Philipp Schöning
wrote:
> Sonicwall Firewalls are dropping fragmented SIP pack
the right course of
action.
Regards,
_
Roman Shpount
On Fri, Dec 21, 2018 at 2:23 PM Moy Amiga wrote:
> Thank you Roman.
>
> But about the RFC 5057, https://tools.ietf.org/html/rfc5057#section-5.1
> And I dont know if this RFC is for the NOTIFY only or also includ
Sorry, BYE message. I blame this on consistent fat-fingering.
:)
_
Roman Shpount
On Fri, Dec 21, 2018 at 1:31 PM Alex Balashov
wrote:
> BUY message? What is this, Broadsoft? :-)
>
> On Fri, Dec 21, 2018 at 01:29:26PM -0500, Roman Shpount wrote:
>
> > You will ne
You will need to send the BUY message. 404 response only cancels the
re-INVITE transaction, not the call. This being said, most SIP
implementations will hang up the call (send BUY) when they receive 404
response to a re-INVITE.
Regards,
_
Roman Shpount
On Fri, Dec 21, 2018 at 12:54
unctionalities or your NAT type is
> not compatible with STUN.
>
There are a lot of good reasons of not using STUN but there are no good
reasons of not using STUN for UDP keep-alive. STUN keep-alive is extremely
easy to implement. It is possible to verify packet valid
On Thu, Nov 29, 2018 at 5:36 PM Alex Balashov
wrote:
> On Thu, Nov 29, 2018 at 05:35:19PM -0500, Roman Shpount wrote:
> Now that the philosophical question is out of the way, what's the right
> SIP response? ;-)
>
>
480 (Temporarily Unavailable) with Retry-After header.
to respond to
devices that misbehave and still allow them to work properly is likely
impossible (i.e. device will likely be flipping gateway status on/off, but
you will need to verify this with each device individually).
Regards,
_____
Roman Shpount
___
Sip
r.
> When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to
> keep the NAT-binding alive.
>
Agreed
_____
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.
On Thu, Nov 29, 2018 at 2:44 PM Alex Balashov
wrote:
> On Thu, Nov 29, 2018 at 02:42:26PM -0500, Roman Shpount wrote:
>
> > Some devices do this to keep a pinhole in NAT firewall open. Pleases see
> if
> > you can enable keep-alive on your proxy and the device for the same
essing the root cause. Other option
is too have proxy to use some sort of in-memory DB to efficiently handle
frequent registrations for devices that do no support SIP keep alive.
Regards,
_
Roman Shpount
___
Sip-implementors mailing list
Sip-im
it is intended for two UA sending INVITE to each other at the same
time, not same UA sending INVITE twice. It will still work for re-INVITE
(not REFER) but it is not the intended usage.
Regards,
_
Roman Shpount
___
Sip-implementors mailing
where SIPS client does not accept
wildcard certificates. I definitely seen other clients that failed to
validate wildcard certificates.
Regards,
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
ted for a proxy to bend a 'sips:' Request URI scheme to
> 'sip:' when adapting TLS to an insecure transport?
>
No, according to the specifications, it is not allowed for the proxy to
change sips to sip. There are numerous implementations which still do it.
Regards,
_
Roman Shpount
__
and, using a custom Via parameter is not standard compliant and
might cause issues with some of the implementations, similar to what Alex
have experienced.
Regards,
_____
Roman Shpount
On Thu, Oct 6, 2016 at 7:45 AM, Neelakantan, Neel <nneelakan...@sonusnet.com
> wrote:
>
On Fri, Sep 30, 2016 at 5:38 PM, Alex Balashov <abalas...@evaristesys.com>
wrote:
> On 09/30/2016 03:52 PM, Roman Shpount wrote:
>
> As far as Via is concerned, the better and standard compliant
>> practice is to encode any application specific data in VIA tag
>>
encryption scheme. It is guaranteed that Via tag will
be returned to the proxy unmodified.
Regards,
_
Roman Shpount
On Fri, Sep 30, 2016 at 3:16 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
> Roman,
>
> On 9/30/16 2:27 PM, Roman Shpount wrote:
>
>> On Fri, Sep 3
ich is needed to
forward such SIP responses is in the Via generic parameter.
Regards,
_____
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
by stateless
proxies to store application specific state. There is no other place to put
it. Skype for business was one example. I can probably find another 10-15
examples similar to that from other products.
Regards,
_____
Roman Shpount
___
Sip
When average processing time is below the normal processing time, then 200
OK response is sent to registration messages.
Regards,
_
Roman Shpount
On Wed, Aug 10, 2016 at 4:22 PM, Michael <n...@spearheadcommunications.ca>
wrote:
> When the initial registration time is met,
,
_
Roman Shpount
On Wed, Aug 10, 2016 at 3:35 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
> Roman,
>
> Interesting. That takes the load off the registrars, but the edge proxies
> still must handle it.
>
> Thanks,
> Paul
>
> On 8/1
messages. When registration messages were refused, proxy would send a 500
error response with Retry-After header set to a random value between 30 and
60 s.
Regards,
_
Roman Shpount
On Wed, Aug 10, 2016 at 11:00 AM, Paul Kyzivat <pkyzi...@alum.mit.edu>
wrote:
> I refreshed
on, the "o=" line of the new SDP MUST be identical to that in
the previous SDP, except that the version in the origin field
MUST increment by one from the previous SDP.*
So, based on this the version should be +1 of the version in the last sent
SDP, i.e. 3.
Regards,
___
ore reason why we use UDP timers for TCP based messages -- it
gives the client time to detect the connection failure and recover the
connection.
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
On Tue, Jul 12, 2016 at 11:48 AM, Dale R. Worley <wor...@ariadne.com> wrote:
> Roman Shpount <ro...@telurix.com> writes:
> > We actually always use UDP like re-transmits even when sending SIP
> messages
> > over TCP or TLS. There are enough implementations that co
ually delivered.
Regards,
_____
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Either re-Invite with new Contact or INVITE-with-Replaces help to
reduce the number of failed calls.
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
On Thu, May 21, 2015 at 10:23 AM, Iñaki Baz Castillo i...@aliax.net wrote:
2015-05-20 23:13 GMT+02:00 Roman Shpount ro...@telurix.com:
I think RFC 7118 example 8.2 is missing that language that WSS is used
based
on the local client policy. This would make the entire example correct
On Thu, May 21, 2015 at 10:40 AM, Iñaki Baz Castillo i...@aliax.net wrote:
2015-05-21 16:37 GMT+02:00 Roman Shpount ro...@telurix.com:
In general, some sort of language that in practical deployments client
would
typically use a local policy to send all the SIP messages through a
pre
is used and what type of connection is being setup.
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
be
discussed in more details in sipcore.
_
Roman Shpount
On Mon, May 18, 2015 at 8:39 AM, Brett Tate br...@broadsoft.com wrote:
In any case, there is no need for WSS URL transport parameter (as
there was never a real need for tls URL transport parameter).
Concerning tls, some
, but it was not clearly stated in the RFC.
In any case, there is no need for WSS URL transport parameter (as there was
never a real need for tls URL transport parameter).
Is your intent to point the issue with the RFC example or to figure out the
correct implementation strategy?
_
Roman
message is sent and the transport used.
One other comment that I had was that sips URI with transport parameter
set to ws should imply requests sent over secure web sockets. I do not
think there is an explicit need for wss URI transport.
_
Roman Shpount
oriented protocols, such as TCP. TLS. or WebSockets. It is a very confusing
and typically mis-implemented scenario.
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman
, which ideally should get
you the same SDP in response, but you should be prepared for a different
SDP as well. The better option is to do a session refresh using an UPDATE
request without SDP.
_
Roman Shpount
___
Sip-implementors mailing list
the caller hang up when they are done waiting for the call to connect. This
is really up to you. The same way you can put maximum call duration at 24
hours and limit calls this way or you can let the caller hang up when they
are done talking.
_
Roman Shpount
On Mon, Jun 23, 2014 at 5:45 AM
to send responses or new SIP messages to the user agent over any flow
that is associated with the same AOR and UID. The continuation of this
discussion should probably take in sipcore.
_
Roman Shpount
On Fri, Jul 27, 2012 at 7:34 AM, Iñaki Baz Castillo i...@aliax.net wrote:
Hi Roman
raw, almost
unimplementable spec which needs to be either updated or replaced (maybe
with sip over websockets :).
_
Roman Shpount
On Mon, Jun 18, 2012 at 4:26 AM, Iñaki Baz Castillo i...@aliax.net wrote:
2012/6/15 Roman Shpount ro...@telurix.com:
SIP Outbound is all about SIP
On Fri, Jun 15, 2012 at 4:50 AM, Iñaki Baz Castillo i...@aliax.net wrote:
2012/6/15 Roman Shpount ro...@telurix.com:
However I do a trick. If my proxy receives a request retransmission
from a different IP:port, it updates its server transaction
information so responses are now sent to the new
or a specification update?
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
header if original connection is closed, but this is almost
universally useless for clients not located on a public IP.
_
Roman Shpount
From: I?aki Baz Castillo i...@aliax.net
Subject: Re: [Sip-implementors] Outbound/GRUU/Path: NO way to receive
in-dialog requests after TCP
NAT?
_
Roman Shpount
On Fri, Jun 10, 2011 at 7:52 PM, Iñaki Baz Castillo i...@aliax.net wrote:
2011/6/10 Roman Shpount ro...@telurix.com:
1. Client registers and creates two TCP flows to two different edge
proxies
2. Client sends an INVITE message to edge proxy 1 which responds
or if there is a better
solution.
_
Roman Shpount
On Fri, Jun 10, 2011 at 8:23 PM, Iñaki Baz Castillo i...@aliax.net wrote:
2011/6/11 Roman Shpount ro...@telurix.com:
Well, I do not think you are correct. First of all, if UA receives a
response over the second flow, it should
and making the authoritative proxy
re-route them over the alternative flow. I am looking for something similar
for responses.
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https
.
_
Roman Shpount
On Tue, Jan 25, 2011 at 11:32 PM, Bob Beers bob.be...@gmail.com wrote:
On Tue, Jan 25, 2011 at 12:26 PM, Roman Shpount ro...@telurix.com wrote:
Does anybody know in which RFC a=encryption SDP attribute is defined? I
see
this attribute used in association with SRTP
Does anybody know in which RFC a=encryption SDP attribute is defined? I see
this attribute used in association with SRTP or RTP encryption, but I cannot
find the standard or a draft that defined it.
_
Roman Shpount
___
Sip-implementors
it can result in SIP messages flowing to a
different client if connection was closed and a different UA opened a
connection using the same origination IP and port, which is common when
multiple UA share the same NAT address.
_
Roman Shpount - www.telurix.com
On Tue, Aug 24
established
which is using a flow to this proxy, this dialog will have to fail, since
there is no way to route the dialog specific requests through any other
flows. Is this correct, or am I missing something?
_
Roman Shpount - www.telurix.com
Correction to my previous message: It is section 3.5.1 CRLF Keep-Alive
Technique that I was referring to, not section 4.4.1.
_
Roman Shpount - www.telurix.com
On Thu, Jun 10, 2010 at 7:39 PM, Roman Shpount ro...@telurix.com wrote:
Hi All,
I am trying to implement
this affects a lot
of implementation and probably because of of this are not properly covered
in RFC 3261.
Roman Shpount www.telurix.com
Date: Fri, 19 Feb 2010 13:51:30 -0800
From: Anders Kristensen ankri...@cisco.com
Subject: Re: [Sip-implementors] Query - are *header
the
header parameters are copied. The RFC 3261 should still match the request
based on To and From tags. Older, RFC 2543 based user agents, will only
match request to dialog if complete To and From headers are preserved.
Roman Shpount www.telurix.com
,
where request would only match the dialog if complete To, From and Call-ID
match.
Roman Shpount www.telurix.com
On Fri, Feb 19, 2010 at 3:22 PM, Paul Kyzivat pkyzi...@cisco.com wrote:
Roman Shpount wrote:
From/To header should be preserved completely with all
I think the key here that end point suppose to indicate that it supports
changing To and From headers in the middle of the dialog. If such capability
is not indicated, changing headers is not allowed.
Roman Shpount www.telurix.com
or at least some discussion on what happens in that case.
P.S. From my experience payload type restriction is really unnecessary and
will just complicate compliant UA.
_
Roman Shpount
___
Sip-implementors mailing list
Sip-implementors
and Policom seem to get
this right. CounterPath declares 8KHz timing in RTP but uses 16KHz RTP clock
(10 ms packets with RTP timestamp incremented by 160). Grandstream declares
RTP clock to be 16Khz and increments RTP timestamp accordingly.
__
Roman Shpount
On 8/8/07, Murat Artun
of bandwidth. Lower bite rates
simply leave space for a side channel inside the audio stream, which,
IMHO, is not extremely useful in an IP environments. Furthermore, you can
decode all of these bit rates as 64KB with minimal affect on the audio
quality.
___
Roman
65 matches
Mail list logo
