at 6:29 PM Rifaat Shekh-Yusef
wrote:
> Hi Maxim,
>
> See my reply inline below.
>
> Regards,
> Rifaat
>
>
>
> On Mon, Sep 14, 2020 at 6:59 PM Maxim Sobolev
> wrote:
>
>> FYI. rifaat.i...@gmail.com bounces... Thanks!
>>
>> -Max
>>
>> --
alternatives?
>
> Regards,
> Rifaat
>
>
> On Thu, Oct 31, 2019 at 1:37 PM Maxim Sobolev
> wrote:
>
>> Hi, I am new here, so not sure what the proper process is, but there are
>> few comments I have with regards to the proposed RFC:
>>
>> 1. In t
I agree "doing nothing wrong" seems like a better verdict. :) Its
implementors could have been more considerate of naive/ignorant
implementations though.
-Max
On Fri., Aug. 14, 2020, 9:13 a.m. Paul Kyzivat,
wrote:
> On 8/14/20 10:25 AM, Maxim Sobolev wrote:
> > Paul, there
Paul, there is no space between colon and the rest of the call-id in the
original example provided. So UAC seems to be doing the right thing I think.
Call-ID: :VaT4082403130oFbc
...
-Max
On Thu., Aug. 13, 2020, 8:15 a.m. Paul Kyzivat,
wrote:
> Pravin, Gaurav,
>
> On 8/13/20 5:34 AM, Pravin Ku
Dear fellow SIP Implementors!
I hope this message on a technical list won't be viewed as spam or noise,
it's just our humble attempt to reach out to a broader audience.
First bit of background: myself and our team at Sippy have been around SIP
for 15+ years now, we have 2.5 of our own SIP impleme
.
-Max
On Tue, Apr 28, 2020 at 10:35 AM Paul Kyzivat wrote:
> On 4/28/20 1:08 PM, Maxim Sobolev wrote:
> > Hi,
> >
> > I've noticed that in the last few years few implementations have gained
> > popularity who use User-Agent in both requests and responses. Instead o
Have you seen RFC3326? It might be just what you are looking for and I
know at least a few implementations that support it to various extent.
-Max
On Tue, Apr 28, 2020 at 2:01 PM Ranjit Avasarala
wrote:
> Hi SIP Experts
>
> there are numerous scenarios where a SIP server would respond with 500
Hi,
I've noticed that in the last few years few implementations have gained
popularity who use User-Agent in both requests and responses. Instead of
User-Agent in requests and Server in responses which I always believed
(perhaps incorrectly) to be the right way of doing it. The argument there
is t
Roland, I think you have a point. There are at least two RFC violations at
play:
1. Seq should be monotonically increasing for a given SSRC unless it
overflows.
2. If you reset SSRC/Seq/TS for whatever reason the new value should be
random, not 0 and all 3 have to be reset together IMHO.
-Max
Hi, is there an equivalent for the X-Forwarded-For in HTTP-land when
dealing with SBCs and B2BUAs? Any RFCs or drafts thereof? Thanks!
-Max
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/lis
On Wed, Feb 10, 2016 at 8:20 AM, Alex Balashov
wrote:
> Seems one can't win. There's got to be a reason this option came about.
> However, it's been around for a long time, and may date back to the mid
> 2000s...
>
> Any empirical knowledge of whether there remain UAs out there nowadays
> that do
ith in a different part
> of the RFC which describes when and where Via headers are added.
>
>
> On 6 October 2015 at 10:23, Maxim Sobolev wrote:
>
>> David, IMHO that "same ordering" clause refers to the "header values"
>> (i.e. individual "via&q
2.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
On Mon, Oct 5, 2015 at 4:23 PM, Maxim Sobolev wrote:
> David, IMHO that "same ordering" clause refers to the "header values"
> (i.e. individual "via" lines), not t
ve. Order of parameters on the
other hand has no particular meaning.
On Mon, Oct 5, 2015 at 4:18 PM, David Cunningham
wrote:
> Hi Maxim,
>
> Surely it says in the text you've quoted "and MUST maintain the same
> ordering"?
>
>
> On 6 October 2015 at 10:10, Max
Sorry, I've obviously put colon instead of semi-colon in my example, the
correct one should read:
SIP/2.0/UDP 1.2.3.4;foo=bar;bar=baz
vs.
SIP/2.0/UDP 1.2.3.4;bar=baz;foo=bar
On Mon, Oct 5, 2015 at 4:06 PM, Maxim Sobolev wrote:
> Hi everybody,
>
> We came across a device tha
Hi everybody,
We came across a device that inserts some non-standard parameter into one
of the Via headers of request and has an issue dealing with situation when
this parameter is moved by our UAS to a different position of that
particular Via header in the response. Therefore, my question is: ar
Paul Kyzivat wrote:
>
> cool goose wrote:
>> Thanks All for pointing me towards some resources. I have never written any
>> protocol stacks before except for few small SIP tools. This would be my
>> first time writing a SIP stack and that's where I felt a need for some
>> literature or books on de
bahan...@hotmail.de wrote:
> Hi,
>
>
> I am newcomer in SIP and Kamailio Wold an have a question.
>
> I have two IP Telefones and would like to realize with Kamailio an IP
> Communication. The Problem:
>
> a. The UA 1 calls UA 2
> b. UA 2 start recording the video form UA 1, before a SIP c
Damir Reic wrote:
> Hi all,
>
> another question...
> If UAS receives BYE on early dialog and answers it with 200OK, does it have
> to respond to initial invite with 487 (same as CANCEL was received)?
Yes. INVITE and CANCEL or BYE transactions complete independently.
Regards,
--
Maksym Sobolyev
sarvpriya wrote:
> HI,
> Can you please tell does MIRIAL support sending of INFO message? If yes then
> how?
It's wrong place to ask. You should have submitted question like this to
the vendor of a particular software.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) E
Krishna Rao Gurram wrote:
> Hi All,
>I have a query about Supported header. Is it must to send
> 'timer' tag extension in Supported: header if Session-Expire:
> 60;refresher=uac/uas header is present in a request?
>
> What should be the behaviour if UAS receives a message includi
Gardell, Steven wrote:
> I suppose that is technically true, but for my own part
> I find announcements about open-source and otherwise academic
> activities useful. I understand that it might be difficult to
> craft guidelines since there are lots of gray areas - and
> certainly such traffic nee
Gregory,
I could be wrong, but I don't think this list is an appropriate place
for product announcements like this.
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Advertisements of any form (for products, software, jobs) is
inappropriate. Announcements related to SIP interope
Iñaki Baz Castillo wrote:
> 2009/3/4 hanifa.mohammed :
>> Hi all,
>>
>> an excerpt from rfc 3261:
>> if the response for a request within a dialog is a 481 (Call/Transaction
>> Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the
>> dialog. A UAC SHOULD also terminate a dialo
stephane wrote:
> I am a bit confused now. Didn't you mean example 2.4? In 2.2 it says
> explicitly
> ... uses either PCMU or PCMA codecs (payload type in RTP packet
> tells which
> is being used) , where in 2.4 two seperate audio streams are
> established.
No, I did not. So, what's unclea
Maxim Sobolev wrote:
> Sorry, you guys were right, I was not. It seems that if Bob accepts only
> one format then the Alice can rely on not receiving any other payload type.
>
> http://www.rfc-archive.org/getrfc.php?rfc=4317
>
> Example 2.1.
>
> In order to allow asymme
Sorry, you guys were right, I was not. It seems that if Bob accepts only
one format then the Alice can rely on not receiving any other payload type.
http://www.rfc-archive.org/getrfc.php?rfc=4317
Example 2.1.
In order to allow asymmetric session, Bob should accept more than one
format, as in e
Iñaki Baz Castillo wrote:
> El Miércoles, 25 de Febrero de 2009, Maxim Sobolev escribió:
>>> Yes, this is the point. Are you sure that devices check that payload
>>> type? or do they assume they will receive the codec negociated in the
>>> SDP?
>> Yes they do.
Klaus Darilion wrote:
> But AFAIK there are embedded devices which load the codec code into the
> DSP once the codec is negotiated, or after reINVITE if the codec
> changes. Thus, with such devices tis would not work. Or if Alice sends a
The practice disagrees with you. All hardware and softwar
Iñaki Baz Castillo wrote:
> 2009/2/25 Klaus Darilion :
>
>>> But if Bob sends G711, how will detect Alice that the incoming RTP is not
>>> G729?
>> There is the payloadtype field in the RTP header. So it is easy to differ
>> them.
>
> Yes, this is the point. Are you sure that devices check that p
Iñaki Baz Castillo wrote:
> 2009/2/25 Klaus Darilion :
>> I think if Alice announces G711 and G729, and Bob answers with G.729,
>> Alice must send with G729 and Bob can send with G711 too. Is this correct?
>
> If Bob answers G729 then Alice expects that Bob will send G729.
> But if Bob sends G711,
Klaus Darilion wrote:
> Hi!
>
> For a certain application where uplink is low bandwidth and downlink is
> high bandwidth I want to use the best available codec - ie. up G729,
> down G.711.
>
> How can I setup such an asymmetric session?
>
> eg.
> high down
> Alice Bob
>
M. Ranganathan wrote:
> You can connect enterprises using only proxy servers. You have to open
> up ports in your firewall and administer firewall rules and dial
> plans.
>
> I leave you with that point of view. Please feel free to explore.
There is one important aspect of B2BUA vs. SIP Proxy tha
Vito Korleone wrote:
> In the scenario that
>
> Bob <-> Alice
> Bob <-> Alice Hangs-up
> and B2BUA initiates a call leg to Carol for Bob..
>
> you can do that with REFER between the subscribers without using a B2BUA
> and the proxy will know that this happened because he "Record Routes".
I doubt
Iñaki Baz Castillo wrote:
> 2009/2/23 Vito Korleone :
>> Hi everybody! I 'm a new member in this group of SIP people :-).
>>
>> So, here's my question,
>>
>> Why "we" need a B2BUA?? Can't we just have the same functionality if
>> we replace him with a proxy and insert the Record Route field to trac
Stephan Steiner wrote:
> Dale
>
> Is there any guidance in an RFC with regards to that? I dug out an older
> thread
> (http://www.opensubscriber.com/message/sip-implement...@cs.columbia.edu/6832126.html)
>
> where Bala said those attributes are global, not codec specific. Is there
> any refer
Prevedini Paolo wrote:
> Hi all,
>
> What is the difference between the expire header value in the INVITE
> message and C timer
Af far as I know Timer C should be used by SIP proxy, while Expire
header is intended for the final UAS to notify it about time constrains.
I don't think those two a
Johansson Olle E wrote:
> audio. Sending DTMF without timestamps and in a different signalling
> path totally removes the relation to the audio stream.
Well, arguably not much relation to audio stream is really needed for
DTMF applications. Relative events ordering, not absolute timestamps, is
Hasini Gunasinghe wrote:
> Hi All,
>
> In my sip soft phone application, I send DTMF using RFC 2976 (through sip
> info message). That works fine and it is related to the SIP stack of our
> application.
> My questions are:
> 1). In implementing the DTMF sending functionality, is it a must that we
Doken, Serhad wrote:
>
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Maxim Sobolev
>> Sent: Friday, January 09, 2009 12:19 PM
>> To: Da
Dale Worley wrote:
> On Thu, 2009-01-08 at 10:21 -0800, Maxim Sobolev wrote:
>> We have come over to a device that generates "strange" SDP. Basically,
>> it splits the same media description into two separate media section. As
>> a result our software considers it
Hi,
We have come over to a device that generates "strange" SDP. Basically,
it splits the same media description into two separate media section. As
a result our software considers it as two separate streams, not as one
which it apparently is.
To me, it seems like the format is invalid, however
Dale Worley wrote:
> On Thu, 2009-01-01 at 13:15 -0800, Maxim Sobolev wrote:
>> It allows you to have different failover timeouts within the same
>> application and select particular one depending on destination.
>
> And interesting idea. My application is a SIP proxy, whic
Dale Worley wrote:
> On Wed, 2008-12-31 at 15:54 -0800, Maxim Sobolev wrote:
>> I believe you are using the wrong tool to implement the required
>> functionality. You should really use application level timeouts to do
>> failover (i.e. cancel call in one UAC and make
Daler Worley wrote:
> How should we handle retry intervals for resending SIP requests which
> have received no response? RFC 3261 prescribes doubling the retry
> interval each time, starting with an interval (T1) which is an estimate
> of the round-trip time of the network, and ending with 32 time
Dale Worley wrote:
> On Mon, 2008-12-29 at 15:35 -0800, Maxim Sobolev wrote:
>> Dale Worley wrote:
>>> Looking at the figure, it appears that Confirmed/Moratorium is allowed
>>> to receive and act on BYE. This seems to be an error to me, but even if
>> I don&#x
Rockson Li (zhengyli) wrote:
> I agree with Maxim here.
> If dialog terminates before transaction, RFC3261 does not say clearly
> if UA need destroy those transactions explicitly or let them complete
> their lifecycle.
> I think it's up to implementation.
That's not exactly my view. I think the U
Dale Worley wrote:
> Looking at the figure, it appears that Confirmed/Moratorium is allowed
> to receive and act on BYE. This seems to be an error to me, but even if
I don't think it's an error. RFC3261 also allows BYE on early dialogs,
so that UAS should be prepared to receive and act on BYE ev
Greg Burrow wrote:
> Thanks all for the information, I should have included the callflow in
> the original message.
>
> |628.190 | INVITE SDP ( g729 telephone-event)
> | |(5060) --> (5060)
> |628.190 | 100 Trying
> | |(5060) <
Kanumuri, Sreeram wrote:
> Both cases are possible. So the UA MUST be ready to accept
> -ACK followed by Bye
> -only Bye (think of a race condition)
I disagree with the latter. It should be "BYE followed by ACK", not just
"only BYE". Don't sending ACK at all would violate RFC causing
unnecessar
Maxim Sobolev wrote:
> Greg Burrow wrote:
>> RFC 5407 appendix A makes it clear that sending a BYE in the early media
>> state is allowed but not recommended. However, what about sending BYE in
>> the Confirmed/Moratorium state?
>> We are seeing a UAC reject the ans
Greg Burrow wrote:
> RFC 5407 appendix A makes it clear that sending a BYE in the early media
> state is allowed but not recommended. However, what about sending BYE in
> the Confirmed/Moratorium state?
> We are seeing a UAC reject the answer SDP from a received 200 message by
> sending a BYE befo
Iñaki Baz Castillo wrote:
> 2008/12/22 karthik karthik :
>> step3.
>> meanwhile the callee has sent 200(invite) without 18x directly.
>> ue<--200(invite)--pcscf<--200(invite)--scscf<--200(invite)--
>> ue--ack-->pcscf--ack-->scscf--ack-->
>> ue sends an ack though it had already sent a cancel.
>>
>>
Paul Kyzivat wrote:
>
> Iñaki Baz Castillo wrote:
>> El Jueves, 18 de Diciembre de 2008, Paul Kyzivat escribió:
>>> You are tying this to the GW because the GW has a cost to you?
>>> If so, then why isn't it the GW that is generating the accounting?
>>>
>>> Or are you saying that you are routing t
Paul Kyzivat wrote:
> The problem here is that you have a device that is trying to charge, but
> controls nothing to enforce its charging. If it wants to charge, then it
> ought to have something (e.g. the media stream) that it can "turn off"
> when the call terminates. Then there won't be fraud
Richard wrote:
> Hi all,
>
> Suppose caller A wants to initiate a video call with B. He sends an
> INVITE to B and B accepts the call and then sends back 200 OK with SDP.
> According to RFC 3264, practically caller B will send the audio and
> video RTP packet to caller A immediately. Since
Iñaki Baz Castillo wrote:
> Hi, I think I already was replied to a similar question but
> unfortunatelly I don't find it.
>
> The question is: when/where is useful sending a REGISTER with a
> Contact different than the UA's contact?
> For example:
>
>
> Phone1:
> - AoR: al...@domain.org
> - List
ROHIT CHAUDHARY wrote:
> Hi,
>
> What should be a response to an INVITE with an empty Proxy-Authorization
> header (i.e. with no value) ?
400 Bad Request, just like any other empty header with no value IMHO.
Header value is not optional.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Intern
Dale Worley wrote:
> On Wed, 2008-12-10 at 13:43 -0800, Maxim Sobolev wrote:
>> Putting port number 0 into m-line should be just enough. Port number of
>> 0 means that the stream has been rejected. Any sensible [UAS] should send
>> a BYE upon receipt of such SDP answer imm
Paul Kyzivat wrote:
>
>
> Maxim Sobolev wrote:
>> Paul Kyzivat wrote:
>>>
>>> Dale Worley wrote:
>>>> On Wed, 2008-12-10 at 13:32 +0530, Nabam Serbang wrote:
>>>>> 1) If the offer being presented in 2xx (200 OK) for INVITE is not
>
Maxim Sobolev wrote:
> 0 means that the stream has been rejected. Any sensible UAC should send
^^^
"UAS" in this case.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1
Paul Kyzivat wrote:
>
> Dale Worley wrote:
>> On Wed, 2008-12-10 at 13:32 +0530, Nabam Serbang wrote:
>>> 1) If the offer being presented in 2xx (200 OK) for INVITE is not acceptable
>>> by UAC, what would be the valid answer in that ACK? Remember this not
>>> re-INVITE which will have prior SDP.
Neelakantan Balasubramanian wrote:
> Looking at RFC 3261, 400 Bad request is a better response. A Reason/Warning
> header can be added in the response.
>
> 21.4.1 400 Bad Request
>The request could not be understood due to malformed syntax. The
>Reason-Phrase SHOULD identify the syntax
Harsha. R wrote:
> Hello,
> i would suggest use of 403 Forbidden.
>
> 415 is usually sent if UAS doesn't like media-type received in
> Content-type header
> 488 is sent for a syntactically correct, but semantically wrong SDP
> offer. Say a mid-call codec modification that is not acceptable.
Hmm
Hi,
I wonder what proper status code UAS should generate for the INVITE that
contains clearly malformed SDP. I see several candidates in 3261:
- 400 Bad Request
- 415 Unsupported Media Type
- 488 Not Acceptable Here
- 606 Not Acceptable
What do people think?
Thanks!
Regards,
--
Maksym Soboly
Harsha. R wrote:
>
>
> 2008/12/5 Maxim Sobolev <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>
> Therefore,UAC core may not even see some of those dupes. IMHO such
> behavior while
> not exactly RFC-abiding is permissive and is
Ujjwal SIngh wrote:
> Hi,
>
> I am simulating a test environment with SIPP and my client UAC
>
> UAC SIPp
>
> INVITE--->
> 180 <-
> 200 OK <
> 2
67 matches
Mail list logo
