I am working on an application and I would like to log the response of the
100 message. What I notice is that when I compare the logging from the
sofia-sip callback handler to the tcpdump trace, I see that the tcpdump
file shows the 100 TRYING message, but I do not see it logged in the sofia
callb
I have resolved this issue.
On Tue, Oct 19, 2010 at 1:27 PM, jonathan augenstine
wrote:
> I am having some issues with setting RFC2833 in the SDP of an INVITE. It
> is not being set correctly so the remote server is responding with default
> inband. Can someone provide an example
I am having some issues with setting RFC2833 in the SDP of an INVITE. It is
not being set correctly so the remote server is responding with default
inband. Can someone provide an example on how to correctly set the RFC2833
in the SDP?
Thank you.
Jonathan
I have a Sofia-SIP nua application that needs to handle a 302 and not
automatically send out a re-invite. I have not been able to identify any
tags that would disable this automatic re-invite. Is there anyway to
disable this feature in the nua library or do I need to implement this using
the nta
I develop a very simple redirect server that is based on the NTA interface.
It works great on Linux. I went to move it to Windows and I am seeing
something that I am not certain how to track this issue down. When I start
the Linux server and logging it turned on, I see the nta log info indicatin
I have been trying to find documentation or examples of how to bridge two
calls and then transfer the media to the new endpoint. Basically, the
server places a call to a SIP URI and the call is established with endpoint
A. Then the server places a call to a second endpoint B. After the call is
e
I am developing a simple redirect server on Windows 2008 Server. When an
invite arrives, the handler performs a database lookup, and then returns a
302 response with the database response in the Contact field. The database
access is about 15-30 milliseconds even under high load. What I am seeing
I have a sofia application that is successfully running on Windows. I
recently had need to port it to Linux. Every thing seemed to be going
successfully with the port. I was able to convert the application and place
some test calls. Then I tried to test multiple calls and what I finally
noticed
What I discovered was that even though the documentation did not explicitly
show the 100 message being handled, it was in fact handled by the client.
For my situation, everything worked as you would hope according to the SIP
protocol.
Jonathan
On Wed, May 13, 2009 at 6:47 AM, Aleksander Morgado <
I encountered the same exact issue. There is not a straightforward way to
disable this, although I do understand it is possible. However, I was
informed that even the nta interface will send a 100 automatically if the
response to the INVITE takes too long. I found the easiest solution was to
mod
, 2009 at 7:57 AM, Pekka Pessi wrote:
> 2009/1/26 jonathan augenstine :
> > Ignore the first trace I sent you. It was incomplete as it overflowed
> the
> > window buffer. I retested and the complete trace is below.
>
> It seems to me that you have copy-pasted wrong ACK code
Does anyone have experience in building Sofia in a Managed C++ environment.
I have built my project and it does both compile and run. However, I am
getting some warning messages that concern me. I have developed on Windows
previously but I have little experience with the .Net and Managed C++
deve
I have two issues that I am struggling with and need some input. The
application I am developing receives an INVITE, does a database lookup, and
redirects the INVITE using a 302 Temporarily Moved response. My first issue
is the sending of a 100 TRYING message. When an INVITE arrives the nua
sofi
I a SIP application I am developing and it is unrelated to a VoIP call. I
want to disable the automatic 100 - Trying response that is sent by the
stack, but my search of the documentation has been unsuccessful in locating
this information. How do I disable the automatic response, so that my
appli
14 matches
Mail list logo