Hi Iñaki,
Thank you very much for sharing this information. I check the same in my
server implementation with various SIP clients and hope this should work
out.
Best Regards,
Vivek Batra
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-bou
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
dont accept that certificate and TLS binding gets failed. I was just trying
to find out if there is any mechanism where multiple identities of server
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kevin
P. Fleming
Sent: Monday, June 13, 2011 9:26 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] CN field in Server C
Correction, I use the second recommended algorithm, which starts playing the
tone on the first received telephone event and plays the tone until one of
the 4 listed listed scenarios occur. This works pretty well as the algorithm
is more responsive to dtmf than waiting for the end of the event to oc
Hi again Vivek,
It occurred to me you're asking: when do you start processing the received
telephone-event payload?
I'm pretty sure this is implementation specific. My implementation processes
tones on the first received packet (minding timestamp problems) which is the
first recommended algorithm
Hi Vivek,
To clarify are you asking how to specify RFC 2833 will be used between both
ends of the call or when to set the market bit in a rtp event packet? I'm
having trouble following your questions.
FYI: RFC 2833 is made obsolete by RFC 4733.
Thanks,
Brandon
-Original Message-
From: s
2011/6/13 Kevin P. Fleming :
> Yes, it is. In addition, if the IP-PBX is generating certs with IP
> addresses in them, or is provisioned with them, and the IP-PBX is behind
> a NAT and has multiple 'identities' that UAs could see, then it should
> be provisioned with multiple certificates and respo
On 06/13/2011 08:54 AM, Iñaki Baz Castillo wrote:
> 2011/6/13 Vivek Batra:
>> However, when IP-PBX is connected behind the NAT router with private IP
>> address assigned on its Ethernet interface (SIP clients on public network
>> can reach IP-PBX through port forwarding), now X-Lite softphone sends
2011/6/13 Vivek Batra :
> However, when IP-PBX is connected behind the NAT router with private IP
> address assigned on its Ethernet interface (SIP clients on public network
> can reach IP-PBX through port forwarding), now X-Lite softphone sends the
> TLS binding request on public interface of rout
For completeness...
RFC 6026 updates RFC 3261 concerning proxy behavior when receiving responses
for unknown requests. The following is from section 4 summary: "It also
forbids forwarding stray responses to INVITE requests (not just 2xx responses),
which RFC 3261 requires."
> -Original M
Hi Folks,
I have encountered one problem during SIP TLS session. I would appreciate
your views on the same;
During TLS binding setup from X-Lite Softphone to our IP-PBX, IP-PBX returns
the server certificate to the X-Lite Softphone. Everything goes fine when
IP-PBX is connected on public IP
Hi Folks,
I would like to know is there any standard practice when to declare DTMF
event in Outband (RFC 2833) viz
1. Whether immediately on receipt of Start Packet without waiting further
for End Packet OR
2. On receipt of Start Packet followed by End Packet OR
3. On receipt of End Packe
12 matches
Mail list logo
