Hi!
I hope everyone stays safe in these times.
During this week’s IETF I ended up in a discussion about using TLS client certs
in SIP. I have been testing this a long time ago, but obviously not fully. The
question I got I failed to find an answer to, which is annoying :-)
Here it goes, let’s s
> On 19 Dec 2018, at 09:28, Richard Phernambucq
> wrote:
>
> Hi Amarnath,
>
> A Re-Invite without SDP is called a late offer and isn't the same as resuming
> a call that was placed on hold.
>
> If 'UAS' wanted to resume the call it should have sent an SDP body with
> sendrecv attribute.
I
> On 16 Aug 2018, at 16:44, Paul Kyzivat wrote:
>
> On 8/16/18 1:21 AM, Sreekanth wrote:
>> On Thu, 16 Aug 2018 at 08:31, Dale R. Worley wrote:
>>> Sreekanth writes:
I am going through the SIP RFC (3261) and couldn't find anything
>>> specified
regarding the 401 Unauthorized challen
> On 18 Nov 2017, at 20:05, Alex Balashov wrote:
>
> Hello Olle,
>
> Thank you for the education!
>
> By way of further question to the list:
>
> On Sat, Nov 18, 2017 at 12:21:09PM +0100, Olle E. Johansson wrote:
>
>> They are important and indic
> On 17 Nov 2017, at 21:21, Alex Balashov wrote:
>
> Hi,
>
> A few questions about TLS. I apologise that they're kind of idiotic,
They are important and indicate that further work is needed here.
Please also engage the SIPCORE wg in IETF with questions like these.
> I'm
> new to SIP over TLS.
Hi!
A while ago the SIP Forum IPv6 working group produced a document on the impact
of IPv6 on IPv4-only SIP implementations, in order to inform developers about
issues found at the SIP Forum SIPit events and in real life tests in other
places. We contributed this document to the IETF but as it
> On 13 Jul 2016, at 17:21, Dale R. Worley wrote:
>
> "Olle E. Johansson" writes:
>>> Requests forwarded between different types of transports where the
>>> proxy's TU must take an active role in ensuring reliable delivery on
>>>
> On 12 Jul 2016, at 17:48, Dale R. Worley wrote:
>
> Roman Shpount writes:
>> We actually always use UDP like re-transmits even when sending SIP messages
>> over TCP or TLS. There are enough implementations that connect TCP or TLS
>> interface with UDP using a stateless proxy which make it nec
> On 12 Jul 2016, at 18:08, Dale R. Worley wrote:
>
> "Olle E. Johansson" writes:
>> THis sounds like a cool test-case for SIPit. [...]
>
>> We do have multiple wifi networks with different properties - bad
>> hotel network, IPv6 only, dual stack, &q
> On 07 Jul 2016, at 20:28, Volkan Hatem wrote:
>
> Cellular radio-access-type changes are even more challenging: 3G to 4G
> (vice versa) in theory should be nearly seamless. But in reality IP
> connectivity will be lost for seconds before it is recovered. What is
> worse, IP address might not e
> On 07 Jul 2016, at 20:31, Brett Tate wrote:
>
>> So far, it seems that a UA could use INVITE-with-Replaces
>> (sent from the new interface to the other party) to
>> transfer the dialog from its old interface to its new
>> interface. Has anyone implemented such a technique?
>
> Yes; with B2BU
> On 07 Jul 2016, at 19:20, Paul Kyzivat wrote:
>
> ISTM that there is dubious likelihood of success of this is attempted after
> the previous connection has already failed. Make-before-break is safer if you
> can get some advanced warning. But make-before-break has its own implications
> on
!
Regards,
/Olle E. Johansson
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> On 20 Jun 2016, at 16:36, Paul Kyzivat wrote:
>
> I'm interested in talking with anybody that has experience implementing SIP
> Outbound. You can contact me privately if you wish.
>
> I'm working on plans for a system that is planning to use outbound, and I
> want to know of issues that oth
> On 30 Mar 2016, at 16:08, Paul Kyzivat wrote:
>
> On 3/30/16 2:58 AM, Arun Arora wrote:
>> On Sun, 20 Mar 2016 23:32:44 +0530, Paul Kyzivat
>> wrote:
>>
>>> On 3/20/16 12:26 PM, Neelakantan, Neel wrote:
Please review RFC 3261. This is addressed in it.
The provisional respons
> On 15 Mar 2016, at 13:38, Brett Tate wrote:
>
> Hi,
>
>>> As far as I know, the main complaint is that it can
>>> temporarily prevent/delay honoring the DNS configured load
>>> balancing and priorities.
>>
>> So there is a consensus that transaction based DNS load
>> balancing is more prefer
> On 17 Feb 2016, at 21:09, Bogdan-Andrei Iancu wrote:
>
> Hi Dave,
>
> We (OpenSIPS project) had several systems deployed (including production)
> with both IPv6 and IPv4, able to do bridging between the two networks at SIP
> level.
>
> What exactly are you looking to be shared ?
The probl
Hi!
If a TLS connection fails - can't agree on cipher, TLS certificate failure or
something similar - is that a failure according to RFC 3263 that makes a client
try next possible connection in the list?
RFC 3263:
"For SIP requests, failure occurs if the transaction layer reports a
503 erro
Which SIP warning code can I use in combination witha 488 response to indicate
that the offer was RTP/SAVP and my UA doesn't support it.
We have warning codes for SIPS but this is more media stream related.
/O
___
Sip-implementors mailing list
Sip-imp
On 21 Mar 2014, at 11:47, Brett Tate wrote:
> The Contact's ABNF is within RFC 3261 section 25.1.
He asked for a header parameter, not the contact parameter. Where's that
documented?
/O
> Your new contact
> parameter must conform to contact-extension. You'd use an equals instead
> of colon.
On 21 Mar 2014, at 11:33, J C Sunil Kumar Reddy wrote:
> Hi All,
>
> I need to send a proprietary parameter in contact header in an INVITE
> message to other end.
> Something like this:
>
> Contact: "Sunil" ;category:strvalue
>
> Here "category:strvalue" is my proprietary parameter. Where "ca
On 11 Feb 2014, at 08:36, Jitendra Singh wrote:
> Hi,
>
> Can any one please suggest whether there are any standard states for SIP
> call (both from caller & callee point of view), defined in any RFCs?
RFC 3261 has states for the INVITE transaction.
RFC 4235 defines a dialog state machine
htt
On 11 Feb 2014, at 08:30, Andreas Byström (Polystar)
wrote:
> Hi
>
> RFC3262 says the following about UAC:
>
> "Note that the PRACK is like any other non-INVITE request within a
> dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request
> when it receives a retransmission of
On 05 Dec 2013, at 16:34, Greg Burrow wrote:
> Paul,
>
> Thanks for the answers. The client restart use case would normally reuse
> the same contact binding (IP address and sip.instance). But what about the
> use case where a client attempts to de-register another clients contact
> binding.
>
om cancel or it needs receive the 487 message ?
>>>>>
>>>>> Best Regards!
>>>>> Casey
>>>>> ___
>>>>> Sip-implementors mailing list
>>>>> Sip-implementors@lists.cs.columbia.edu
Hi!
I'm trying to understand the offer/answer aspects of using SDES.
If the offerer sends something like:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:KEYSTUFF|2^28
There's a key lifetime given.
Does the answer have to use the same lifetime?
What if the answer contains no lifetime?
The lifetime
more
here:
http://www.sipforum.org/content/view/398/286/
See you on the mailing list!
Best regards,
/Olle E. Johansson
Co-Chair of the SIP Forum IPv6 wg
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu
26 jun 2013 kl. 14:32 skrev Brett Tate :
> Hi,
>
> If they are use OPTIONS to determine call/subscription/dialog state...
>
> Does anyone know what response they are expecting to receive when there is no
> dialog usage?
>
> Does anyone know the RFC snippet indicating what should be sent and h
Hi!
The SIP Forum IPv6 working group has been working for a while with the
migration to IPv6 in the SIP protocol. Our first IETF draft documents some
issues with IPv4-only applications that receive messages from IPv6
implementations. What happens if you get IPv6 in a via header, in a
record-ro
Hi!
I just wanted to promote the work done by the SIP Forum's working group for
IPv6 where I'm a co-chair. If you are interested, there's a mailing list and
regular conference calls - the next one today at 18.00 UTC.
We are working on a few IETF drafts to handle dual stack connection setup
("H
22 maj 2013 kl. 19:45 skrev Brett Tate :
>>> Hello. I did that, but I dont have some docs
>>> to compare and determine is what the client
>>> is doing is correct or not,
>>
>> http://tools.ietf.org/html/rfc3261
>>
>> The ultimate reference to SIP.
>> /O
>
> Since RFC 3261 doesn't provide muc
22 maj 2013 kl. 19:20 skrev Milton Sanchez :
> Hello. I did that, but I dont have some docs to compare and determine is
> what the client is doing is correct or not,
http://tools.ietf.org/html/rfc3261
The ultimate reference to SIP.
/O
> thanks.
>
>
> On Wed, May 22, 2013 at 1:55 PM, Nahum Nir
21 maj 2013 kl. 11:19 skrev isshed :
> Anand
>
> the received parameter is added by your own stack(one who received the
> request). It contains real IP from where the packet is received. In case of
> NAT it will be NAT IP.
That seems like a broken NAT. If you are inside of a NAT and receive a me
21 maj 2013 kl. 11:05 skrev ANAND KUMAR :
> Section 18.2.2 Sending Responses (For servers) of rfc3261 says:
>
> if the top Via has a "received" parameter, the response MUST be sent to the
> address in the "received" parameter, using the port indicated in the
> "sent-by" value, or using port 5
14 mar 2013 kl. 13:10 skrev Khoa Pham :
> Hi,
>
> AFAIK, ICE is used to detect as many ways as possible to send media stream
> to the other client. If it can't find, it will use TURN protocol to
> determine media relay proxy.
>
> How can ICE detect many ways? Can we benefit from ICE if we're in
14 mar 2013 kl. 05:52 skrev satya r :
> hi All,
>
> plz give me a scenario of
> 1.call transfer
> 2. call forward
> 3.call park
> its very urgent for me plz solve it
https://tools.ietf.org/html/rfc3665
/O
___
Sip-implementors mailing list
Sip-impleme
8 jan 2013 kl. 18:40 skrev Paul Kyzivat :
> On 1/8/13 10:51 AM, Arun kalia wrote:
>> There is a test suite which has 100% coverage of the spec, if it is run
>> against the product and it shows 100% PASS. Then yes, of-course the
>> product is 100% compliant.
>
> In that case it is up to the publ
The SIPit 30 site is now updated with venue and hotel information. Make sure
you register early!
https://www.sipit.net/Main_Page
Test will this year - apart from the usual - include SIP Outbound, SIP/TLS,
SIP/ipv6 and SIP over Websockets/WebRTC.
If you have other things you want to test, just a
11 dec 2012 kl. 14:24 skrev "Kumar, Puneet (Puneet)" :
> Hello,
>
> I have a scenario which has below SIP signaling.
>
> UAC UAS
> -INVITE> (1)
> <--200 (2)
> --ACK> (3)
> -INVITE--
11 dec 2012 kl. 13:29 skrev ikuzar RABE :
> Hi all,
>
> I'd like to know what are the differences between Request-URI and to URI ?
> from URI and contact URI ?
URI is a generic concept, a SIP address, like sip:t...@example.com
Request-URI is the URI in the first line of a SIP request.
>From U
Hi!
The Kamailio project is working on implementing SIP Outbound (RFC 5626) both as
a registrar and edge proxy.
We have ended up in a discussion on what to do if the contacts are not the same
in two registrations with the same instance ID and different reg-id's. Let's
say there are two differ
To add a detail: Any offer can only get ONE answer from the SAME client.
Remember that a SIP INVITE can fork, so one offer can get one answer in 183
from one device and a different one in 200 OK from *another* device. That's
valid.
This is covered in more detail in the RFCs covering the SIP Offe
16 aug 2012 kl. 16:43 skrev Iñaki Baz Castillo:
> Thanks to both. It's clear. I had some doubts since RFC 3265
> (obsoleted by 6665) allows multiple subscription dialog creation if a
> proxy forks a SUBSCRIBE. But those dialogs are created in the UAC upon
> receipt of each NOTIFY with different F
14 jun 2012 kl. 17:51 skrev Iñaki Baz Castillo:
> Hi, please correct me if I'm wrong but Outbound/GRUU has a design
> "issue" when the TCP connection is closed (i.e. SIP outbound proxy
> disconnection). Scenario:
>
>
> alice -- OB-1 -- PROXY/REGISTRAR -- OB-2 -- bob
>
>
> - Bo
15 apr 2012 kl. 19:31 skrev Kevin P. Fleming:
> On 04/15/2012 12:23 PM, Vineet Menon wrote:
>
>> Ya I agree that initiating a new transaction just for convey non-auth.
>> seems messy.
>
> i think you've missed the important point here: if you send a SIP
> request to a UAS, you are implicit
15 apr 2012 kl. 16:32 skrev Vineet Menon:
> Ho Olle,
>
> So, is that the issue with not being able to authnticate response messages,
> that how to convey the sender that one is unable to say whether he was able
> to auth. the response???
>
> I thought it would be regarding something else in
14 apr 2012 kl. 16:34 skrev Vineet Menon:
> Hi,
>
> I was going thru RFC 4474 which talks about certificate based
> authentication in SIP. Page no 5 says that the scope of this rfc is only in
> authenticating request messages.
> It says that response messages cannot be authenticated based on thi
11 apr 2012 kl. 18:07 skrev Paul Kyzivat:
> On 4/11/12 11:48 AM, Olle E. Johansson wrote:
>>
>> 11 apr 2012 kl. 17:18 skrev Paul Kyzivat:
>>
>>> On 4/11/12 10:37 AM, Alex Balashov wrote:
>>>> Between RFC 3398 and 4694, I am unclear on whether the &#
ition of
> npdi as a sip uri parameter. But its my understanding that this is a
> fairly common mistake - to the point that SBCs are prepared to deal with it.
>
> Thanks,
> Paul
> ___
> Sip-implementors mailing
4 apr 2012 kl. 18:21 skrev Worley, Dale R (Dale):
> - a locally-generated ringback tone for each 180 Ringing that has
> been received (or perhaps one ringback tone for all of the 180's
> together)
Unfortunately many pstn gateway services deliver ringback in 183, making it
very hard to underst
"
15.4.1.3
Unknown SIP-PBX Identity
The SP-SSE MUST issue a 404 Not Found response to a REGISTER request, if the
Registration AOR of the SIP-PBX is not found in its database. An SIP-PBX
receiving such a response to a REGISTER request MUST consider the Registration
attempt to have failed, and not
11 nov 2011 kl. 00:58 skrev Hadriel Kaplan:
>
> On Nov 9, 2011, at 3:43 AM, Olle E. Johansson wrote:
>
>>
>> 8 nov 2011 kl. 15:47 skrev Worley, Dale R (Dale):
>>
>>> In the real world, the "felt need" for security is not "I don't want
&
8 nov 2011 kl. 22:06 skrev Kevin P. Fleming:
> On 11/08/2011 02:54 PM, Iñaki Baz Castillo wrote:
>> 2011/11/8 Kevin P. Fleming:
So my web browser (that includes the list of Root CA certificates)
inspects both certificates, realizes that the first one is an
intermediate CA certifica
8 nov 2011 kl. 15:47 skrev Worley, Dale R (Dale):
> In the real world, the "felt need" for security is not "I don't want
> the government to find out." but rather "I don't want my wife to find
> out."
:-)
While I agree with what you say in regards to PSTN, I'm still waiting for the
tabloids to
8 nov 2011 kl. 15:51 skrev Iñaki Baz Castillo:
> 2011/11/8 Worley, Dale R (Dale) :
>>> From: Olle E. Johansson [o...@edvina.net]
>>>
>>> I'm trying to figure out why after more than ten years of SIP in the
>>> industry, we're stil
8 nov 2011 kl. 12:55 skrev Iñaki Baz Castillo:
> 2011/11/8 Hadriel Kaplan :
>> Heh, you forgot your tags again. ;)
>
> Yes, but it should be <95%-joking> :)
>
>
>
>> Some of the reasons S/MIME isn't usable for SIP are described in RFC 3261
>> itself, in various places in section 23 and its
8 nov 2011 kl. 04:57 skrev Hadriel Kaplan:
>
> On Nov 7, 2011, at 4:54 PM, Iñaki Baz Castillo wrote:
>
>> 2011/11/7 Olle E. Johansson :
>>>>> And why do you compare S/MIME in SIP with a unicorn?
>>>>
>>>> Because both are theoretica
7 nov 2011 kl. 22:54 skrev Iñaki Baz Castillo:
> 2011/11/7 Olle E. Johansson :
>>>> And why do you compare S/MIME in SIP with a unicorn?
>>>
>>> Because both are theoretically possible but have not been found in the wild?
>>
>> And does anyone s
7 nov 2011 kl. 16:53 skrev Worley, Dale R (Dale):
>> From: Hadriel Kaplan [hkap...@acmepacket.com]
>>
>> But this S/MIME discussion is like arguing about the length of horn a
>> unicorn must have. ;)
>
> Ah, but it's so much more interesting to argue about the universal
> properties of the memb
7 nov 2011 kl. 14:23 skrev Hadriel Kaplan:
>
> On Nov 7, 2011, at 2:18 AM, Olle E. Johansson wrote:
>
>>
>> 7 nov 2011 kl. 04:47 skrev Hadriel Kaplan:
>>
>>> But this S/MIME discussion is like arguing about the length of horn a
>>> unicorn must
7 nov 2011 kl. 04:47 skrev Hadriel Kaplan:
> But this S/MIME discussion is like arguing about the length of horn a unicorn
> must have. ;)
And why do you compare S/MIME in SIP with a unicorn?
Curious.
/O
___
Sip-implementors mailing list
Sip-impleme
The closest thing I can think of is S/MIME signatures and certificates that of
course are encoded in text, but is not text in the data.
There are actually references to sending images in RFC 3261:
"The disposition type icon indicates that the body part contains an image
suitable as an iconic rep
31 okt 2011 kl. 15:46 skrev Worley, Dale R (Dale):
>> From: Olle E. Johansson [o...@edvina.net]
>>
>> RFC 3261 is not totally clear in the topic of AORs you can register
>> to. It seems to indicate any URI, but mentions usernames in most
>> examples.
>
> I
RFC 3261 is not totally clear in the topic of AORs you can register to. It
seems to indicate any URI, but mentions usernames in most examples. The
definition of address-of-record is
" Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
that points to a domain with a loc
The SIP identity RFC 4474 talks about "SIP Domain certificates" but doesn't
really specify the syntax. There's a lot of text about them and parts are a bit
confusing, mixing "host name" with "domain". It mentions "subject alt names" in
one part, but not in the important parts that only talks abo
The SIP Forum's test event SIPit #29 will be hosted by ETSI October 24–28, 2011
in Monte Carlo, Monaco. It's an important event for all of you that wants to
test your code, meet other SIP developers, meet authors of RFCs and - in
general - spend one week working hard with SIP.
SIPit covers all
14 jul 2011 kl. 16.11 skrev Iñaki Baz Castillo:
> 2011/7/14 Olle E. Johansson :
>>> I assume it's just a private/custom vendor specification working on
>>> its own devices (and just that).
>> No, many vendors use it. And if it was private, shouldn't they use
14 jul 2011 kl. 14.14 skrev Iñaki Baz Castillo:
> 2011/7/14 Olle E. Johansson :
>> While working with a platform in Germany I noticed that one server sends
>> NOTIFY events in-dialog for a call with event types "talk" and "hold".
>> These are n
While working with a platform in Germany I noticed that one server sends NOTIFY
events in-dialog for a call with event types "talk" and "hold".
These are not registred with the IANA as event types.
Broadsoft documentation from 2005 specifies them:
http://track.sipfoundry.org/secure/attachment/17
7 jul 2011 kl. 20.22 skrev Iñaki Baz Castillo:
> 2011/7/7 Iñaki Baz Castillo :
>> 2011/7/7 Iñaki Baz Castillo :
>>> 2011/7/7 Brez Borland :
I think transport/transaction layers should work to prevent cases like
this.
Personally I would look to close the previous connection associa
7 jul 2011 kl. 18.04 skrev Iñaki Baz Castillo:
> 2011/7/7 Olle E. Johansson :
>> Right so the question is if we can add a valid domain in the Via - one that
>> matches the cert.
>
> The Via header is added (usually) by the transaction layer (who knows
> which transport
7 jul 2011 kl. 17.56 skrev Iñaki Baz Castillo:
> 2011/7/7 Olle E. Johansson :
>> Well, the question is what to put in the Via header. You need something that
>> points back if you have transaction state in one of your proxys... The
>> received parameter helps with that.
7 jul 2011 kl. 17.15 skrev Brez Borland:
> On Thu, Jul 7, 2011 at 3:56 PM, Olle E. Johansson wrote:
> > Why would Proxy B want to _validate_ the certificate of Proxy A if it have
> > not done so when Proxy A established a connection? Proxy B might want to
> > _verify_ t
7 jul 2011 kl. 16.28 skrev Iñaki Baz Castillo:
> 2011/7/7 Olle E. Johansson :
>>> Proxy B should not discard data(certificates previously received)
>>> associated with Proxy A when it tries to reconnect to it. I think Proxy B
>>> should retain the certif
7 jul 2011 kl. 16.50 skrev Iñaki Baz Castillo:
> 2011/7/7 Brez Borland :
>> Why would Proxy B want to _validate_ the certificate of Proxy A if it have
>> not done so when Proxy A established a connection? Proxy B might want to
>> _verify_ that Proxy A presented the same certificate when Proxy B f
7 jul 2011 kl. 16.45 skrev Brez Borland:
> On Thu, Jul 7, 2011 at 3:11 PM, Olle E. Johansson wrote:
>
> > > 2) not perform validation of the upstream element cert. Because by
> > > forwarding a response, by definition, it acts as a server in this
> > > par
7 jul 2011 kl. 14.11 skrev Brez Borland:
> On Thu, Jul 7, 2011 at 12:09 PM, Iñaki Baz Castillo wrote:
> 2011/7/7 Brez Borland :
> > I think once TLS context is invalidated(i.e. rejected to be resumed by Proxy
> > A), Proxy B should either:
> >
> > 1) return an error to the downstream UAS (i.e. f
7 jul 2011 kl. 10.34 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson :
>>> Yes, always. Responses for request arrived via TCP/TLS/SCTP must reuse
>>> the same connection if available.
>
>> But SIP outbound says that this only applies when we have mutual T
nteresting. Yes, the TCP layer is not interesting in a TLS
session, all we care about is the TLS connection state. Now, I don't think TLS
can survive a TCP breakdown, but that's something we'll propably have to look
into. Anyone that can explain this?
/O
> Comments please,
&g
6 jul 2011 kl. 18.19 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson :
>> - A proxy (A) forwards a SIP request with a SIPS r-uri to another proxy (B).
>> The VIA header indicates SIPS and has a domain name. The proxy that receives
>> the request shows a server CERT
6 jul 2011 kl. 17.28 skrev Brez Borland:
> On Wed, Jul 6, 2011 at 4:13 PM, Iñaki Baz Castillo wrote:
> 2011/7/6 Olle E. Johansson :
> >> Good question. However, checking a server certificate (matching the
> >> domain) just makes sense (IMHO) for requests. This is, an UAC
6 jul 2011 kl. 16.26 skrev Brez Borland:
> Hi Olle, please see below..
>
> On Wed, Jul 6, 2011 at 3:15 PM, Olle E. Johansson wrote:
>
> 6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo:
>
> > 2011/7/6 Olle E. Johansson :
> >> Now, consider that a UA has config
6 jul 2011 kl. 16.01 skrev Iñaki Baz Castillo:
> 2011/7/6 Olle E. Johansson :
>> Now, consider that a UA has configured a proxy as an outbound proxy. The
>> connection between them is out of scope for now.
>>
>> The UA issues a call to SIPS:al...@georgia.example.com
During a discussion with OpenSER/Kamailio developers about TLS and SIPS we've
come up with a number of issues we can't sort out.
Now, consider that a UA has configured a proxy as an outbound proxy. The
connection between them is out of scope for now.
The UA issues a call to SIPS:al...@georgia.e
14 jun 2011 kl. 06.23 skrev Vivek Batra:
> Hi Iñaki,
>
> This is the exact problem. If server only uses domain based TLS
> certificates, SIP clients which have been used IP Address to reach server
> don’t accept that certificate and TLS binding gets failed. I was just trying
> to find out if the
12 maj 2011 kl. 15.11 skrev Iñaki Baz Castillo:
> 2011/5/12 Olle E. Johansson :
>>> Hi Olle, what do you mean with "username part options"? maybe you mean
>>> something like:
>>>
>>> sip:alice;param=1...@atlanta.com
>>
>> Yes. So
12 maj 2011 kl. 15.03 skrev Iñaki Baz Castillo:
> 2011/5/12 Olle E. Johansson :
>> Which RFC describes the URI username part options? I fail to find it...
>
> Hi Olle, what do you mean with "username part options"? maybe you mean
> something like:
>
> sip
Which RFC describes the URI username part options? I fail to find it...
/O
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
5 maj 2011 kl. 13.42 skrev Iñaki Baz Castillo:
> 2011/5/5 Olle E. Johansson :
>>> Yes, RFC 3261 says that devices must use upper-case for SIP version
>>> field. But as per BNF grammar in RC 3261, they MUST accept lowercase.
>>>
>>
>> Was the rule chang
5 maj 2011 kl. 12.39 skrev Iñaki Baz Castillo:
> 2011/5/5 Harbhanu sahai :
>> Is this testcase correct as per 3261 text ?
>
> Yes, RFC 3261 says that devices must use upper-case for SIP version
> field. But as per BNF grammar in RC 3261, they MUST accept lowercase.
>
Was the rule changed betwe
3 maj 2011 kl. 15.02 skrev Iñaki Baz Castillo:
> 2011/5/3 Olle E. Johansson :
>> SiP identity is used by a proxy that hosts a domain to verify a SIP identity
>> within that domain, basically telling the other part that "I am sure that
>> o...@edvina.net is authorized
3 maj 2011 kl. 14.49 skrev Iñaki Baz Castillo:
> Hi, RFC 4474 defines the Identity mechanism in which a proxy asserts
> the identity of a request originator by appending a Indentity and
> Identity-Info header.
> In the other side, RFC 5922 defines client-to-server and
> server-to-client authentic
3 apr 2011 kl. 13.23 skrev Iñaki Baz Castillo:
> 2011/3/31 Olle E. Johansson :
>> If you are sending only ringback, I would recommend sending 180 with SDP
>> instead of 183. If you're sending 183, I can't move my state machine to
>> ringing state, which would h
31 mar 2011 kl. 15.42 skrev Worley, Dale R (Dale):
>
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor
> [nitinkapo...@gmail.com]
>
> I am facing the issue with one of my
23 mar 2011 kl. 10.48 skrev pranab sahoo:
> Hi All
> Thanks all of you providing a platform to clarify sip doubts
>
> can we use any other algorithm than md5 during registration process?
>
>
http digest auth with MD5 is the current implementation - even though many of
us believe we should mov
22 mar 2011 kl. 15.45 skrev Worley, Dale R (Dale):
> In a sense, the SBC is allowed to reject any request it doesn't like for any
> reason, because it is a B2BUA.
>
> But a well-behaved SBC should accept any syntactically valid Record-Route
> header, and as far as I can tell without sending th
Hello,
I've started collecting various threads around SIP & IPv6 on my web site and
also compiled an action plan in version 0.8 ;-)
Please take a few moment to go through it and give me feedback. I might be
totally off track - but at least we need to start doing something.
- Action plan: http
15 feb 2011 kl. 11.17 skrev Iñaki Baz Castillo:
> 2011/2/15 Olle E. Johansson :
>> Yes that was my conclusion as well. In the beginnning, I fell into the same
>> trap as Dale, reading that SIP is Unicode. But there are many unclear areas
>> and I think we need to docume
15 feb 2011 kl. 09.20 skrev Saúl Ibarra Corretgé:
>> Does the ABNF for SIP uri's really support this?
>>
>
> AFAIS not:
>
> hostport = host [ ":" port ]
> host = hostname / IPv4address / IPv6reference
> hostname = *( domainlabel "." ) toplabel [ "." ]
> domainlab
14 feb 2011 kl. 19.16 skrev Iñaki Baz Castillo:
> 2011/2/10 Worley, Dale R (Dale) :
>> I would argue for the opposite convention: The URI should contain the real
>> domain name, since "everything in SIP is encoded in UTF-8". Only at the
>> point of resolving the domain name into destination a
1 - 100 of 152 matches
Mail list logo
