Check the refdocs for the msg_get_address() function.
Instead of checking the 200 OK, consider using DNS to resolve the address set
for the proxy URI. It should be in the local DNS cache, so fairly little
overhead would be required in the common case.
-Jarod
From: Jerry Richards [mailto:jerry
re.
-Jarod
--
From: Louis Guindon [mailto:louisguin...@vtech.ca]
Sent: Thursday, October 13, 2011 1:23 PM
To: Jarod Neuner
Cc: sofia-sip-devel@lists.sourceforge.net
Subject: RE: [Sofia-sip-devel] 183 early media description different from 200Ok
media desription
Hi Jarod,
Tha
Three points of interest here.
1) By default, NUA supports the 100rel extension described in RFC3262. Since
the proxy is sending a 183 response, it seems likely that it is requesting a
PRACK. Have those messages been omitted in the provided call flow?
2) If the proxy was not requesting a PRAC
Yeah, I mixed up 3 and 4. Part 4 is in tport_tls.c, in the method
tls_init_context().
-Jarod
From: Inca Rose [mailto:incar...@gmail.com]
Sent: Tuesday, January 04, 2011 10:42 AM
To: Jarod Neuner
Cc: sofia-sip-devel@lists.sourceforge.net
Subject: Re: [Sofia-sip
Not sure if this is necessary, but UniMRCP probably has to set the Accept:
header to in the OPTIONS request to application/sdp.
If not, UniMRCP should check the OPTIONS response for Content-Type: and
Content-Length: fields to determine if an application/sdp was sent with the
response.
If a S
Should take four changes in tport/ to add this capability.
1) Add new string tags for the certificate passphrase. (tport_tag.c and
sofia-sip/tport_tag.h )
2) Extend the tls_issues_t structure with a field for the passphrase.
(tport_tls.h)
3) Parse for the new tag in tport_tls_init_master() and s
> How can I tell sofia to send all messages for a specific handle with the same
> transport type?
You can, but it will likely break the transport layer. The UAC that creates
the dialog/handle specifies the transport that is used.
> Do I have to use the sips-schema? And if so do I have to use
Calls to nua_respond, or any other method that sends or receives a response,
should always be considered an async operation. A reasonable approach would be
to use the memory home associated with that handle (nua_handle_home) to
allocate the data - the data would be automatically released when t
There is only one:
http://tools.ietf.org/html/rfc3261
Once you have a good handle on the core protocol, the interesting stuff
is referenced here:
http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-06
On Mon, 2009-06-08 at 11:50 -0500, David Wells wrote:
> Hello All,
>
>
>
> I was wo
sendrecv is the default when the mode is omitted, so if you can, file a
bug report with your vendor.
If that isn't an option, you could hack the sdp_print() attribute
'sdp_f_mode_always' into soa.c and get the same result.
On Thu, 2009-03-26 at 04:07 -0500, Jean Dumercq wrote:
> Hello everybody,
RFC3361 is only supported by virtue of sofia-sip's support of an
outbound proxy. The application is responsible for retrieving option
120 from the DHCP client and passing it to the sofia-sip stack.
On Mon, 2009-03-23 at 12:31 -0500, Gustavo García wrote:
> Hi folks,
>
> According to the sofia-si
Two problems.
1) It looks like the stack called bind() with AF_INET, not AF_INET6. On
most (all?) implementations, a IPv6 socket can connect to a IPv4
address, but an IPv4 socket cannot connect to an IPv6 address.
Maybe NUTAG_URL("sip:*;maddr=[::]") will work?
2) At present, you cannot send mes
On Fri, 2009-02-13 at 08:20 -0600, Andrew Rechenberg Lists wrote:
> Unfortunately I'm a little light on endianess knowledge :)
Unfortunately I'm pretty light on autoconf, so I don't know what would
have caused such an event.
> I'm compiling just the libsofia-sip-ua code in XCode and I'm using the
On Wed, 2009-02-11 at 07:03 -0600, Andrew Rechenberg Lists wrote:
> Looks like su_inet_ntop isn't working in my case. The su_family is 528
> which defaults to su_seterrorno(EAFNOSUPPORT).
I completely overlooked this earlier. Is the iPhone little endian?
http://sofia-sip.sourceforge.net/refdocs
On Thu, 2009-02-12 at 09:18 -0600, Andrew Rechenberg Lists wrote:
> Here are a working and non-working TPORT_LOG=9 (1.12.9 works,
> 1.12.10/darcs HEAD doesn't). Not much more there than what I posted
> initially (at least from my layperson's point of view :) ).
Indeed. The silence is rather distr
Just trying to make tport_tls init a bit noisier.
New patches:
[tport_tls: add/fix some tls init logging
Jarod Neuner **20090212180248] {
hunk ./libsofia-sip-ua/tport/tport_tls.c 267
- tls_log_errors(1, "tls_init_context", 0);
+ tls_log_errors(3, "tls_init_context",
On Wed, 2009-02-11 at 09:01 -0600, Andrew Rechenberg Lists wrote:
> > tport_listen(0x1029630): tport_setname(pf=2, tls/(null)): Address
> > family not supported by protocol family
Interesting. Can you provide a log with TPORT_DEBUG set to 9?
> > Do I need to change something in my code to get
On Mon, 2009-02-09 at 09:21 -0600, mikhail.zabal...@nokia.com wrote:
>
> The stack has no clue by default. It binds to INADDR_ANY and
> uses the first interface entry for the source address.
I just glanced at the code...it looks like IPv6 follows this same
behavior too. This ma
On Thu, 2009-02-05 at 17:23 -0600, Jerry Richards wrote:
> Hello All,
>
> Could someone tell me generally what I need to change to send SIP messages
> over an IPv6 network. Is it simply a matter of substituting the IPv6
> address where ever I normally put the IPv4 address?
Basically, yes. NUT
seful, but the idea is there if it ever proves necessary.
Cheers~
-Jarod
New patches:
[TLS Subject Checking in tport
Jarod Neuner **20090114184543
sofia-sip/tport.h:
* tport_delivered_from_subjects() returns type (su_strlst_t const *)
* Export tport_subject_search()
sofia-sip/t
On Wed, 2009-01-07 at 16:19 -0600, Jarod Neuner wrote:
> On Wed, 2009-01-07 at 11:44 -0600, Pekka Pessi wrote:
> > Also, if we want to do some automated Subject testing at tport level,
> > I'd go for using tpn_canon which should contain the domain name used
> > in the SI
Pekka,
Thanks for the quick response.
On Wed, 2009-01-07 at 11:44 -0600, Pekka Pessi wrote:
> tpn_subject breaks the binary compatibility
I was wondering if that would be an issue. The point was to get the
subject into vtp_connect() and perform subject verification before
tport_send_event()
New patches:
[TLS Subject Checking in tport
Jarod Neuner **20090105222710
sofia-sip/tport.h:
* Add (tp_name_t *)->tpn_subject
- The peer of an outgoing connection must present a matching
subject in its certificate.
* tport_delivered_from_subjects() returns type (su_strlst_t const *)
*
of the peer certificate.
These patches should not change the behavior of NTA or NUA.
Tue Dec 16 11:58:26 CST 2008 Jarod Neuner
* Helper functions for vtp_connect and vtp_wakeup_pri.
- Expose tport_setname() and tport_wakeup() via tport_internal.h
- Add tport_register_secondary() for
On Wed, 2008-11-26 at 12:46 -0600, Pekka Pessi wrote:
> 2008/11/19 Paulo Pizarro <[EMAIL PROTECTED]>:
> > This patch adds support to a new tag called TPTAG_TLS_VERIFY_PEER.
>
> I wonder if someone is using the sekret environment variable
> SSL_VERIFY_PEER, it is probably their time to yell...
I wa
On Tue, 2008-11-18 at 10:49 -0600, Jerry Richards wrote:
> Anyone know the answer to the question below? Does sofia-sip only use
> "agent.pem" and "cafile.pem"? No other pem files are needed or specified?
> I'm somewhat new to SSL/TLS.
Correct.
"cafile.pem" should be the certs from all certi
,CANCEL,OPTIONS,PRACK,BYE"
>Allow: INVITE, ACK, CANCEL, OPTIONS, PRACK, BYE
>Supported: timer, 100rel, path
>Content-Length: 0
>
>
This patch corrects that behavior.
New patches:
[sip
This patch attempts to correct for the clock drift that results from
using poll() to do timing.
It still will not generate extra signals for missed timer events, but
assuming that timer events are never missed, the average interval time
will always be equal to the requested interval time.
-Jaro
I believe you want something like this:
NUTAG_URL("sip:*:5060"),
NUTAG_M_PARAMS("transport=tcp")
On Fri, 2007-08-03 at 02:15 -0500, rajeev k wrote:
> Hi,
>
> To force the application to use tcp I am using following tag with
> nua_set_params. It works fine except that the tcp will use random
> po
29 matches
Mail list logo
