Hello,
Is there a simple way to replace all occurences by an other string using the
strcture "subst_expr" ?
Thanks,
Nicolas
Découvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Baléares et la Rép. Dominicaine sur Yahoo! Voyages :
http://fr.travel.yahoo.com/promotions/mar14.html
Hi all,
does anyone know what the reason might be for SIP clients (XLite and
other) on certain Ip addresses not responding to the
www_authenticate() challenges sent by the Sip proxy?
I can see (with ngrep) that the clients send register requests to SER,
and I also see SER sending back challenge packets. Anyway, no
challenge response is sent back from the client, but a normal
REGISTER. XLite diagnostic log does not show any challenge request
packets being received by the client.
My first assumption would be a routing problem between the ISPs
networks, but this all happened suddenly after a restart of my SER
machine, even though nothing on the configuration has been changed.
On some machines(resp. ISPs), the client registers successfully and
can dial out other SIP clients, but does not receive any incoming
calls. On other - everything works perfectly both ways.
Pls give me any clues or suggestions if u can...
Hi ALL,
I am a newbie on DNS configuration stuff, so need help to configure DNS SRV record for SER installation.
For it, I just added following two lines to the concerned zone file:
sip.mydomain.com. IN A ip.ad.re.ss
_sip._udp.mydomain.com. SRV 0 0 5600 sip.mydomain.com.
Then I restart DNS(BIND) by Plesk.(Is there a problem?) And I did and got:
# dig sip.mydomain.com :It was answered correctly
# dig _sip._udp.mydomain.com :It was answered correctly
# dig -t SRV _sip._udp.mydomain.com :No answer.
Is there something wrong? Or am I missing something here?
I would really appreciate your help.
Thank you,
Jay Lee
Whenever two UAs try to establish a voice connection, rtpproxy crash and
I get the following message in my log file but there have no problem
with the conversation.
Mar 18 01:09:30 perch /usr/sbin/ser[4070]: ERROR: send_rtpp_command:
can't send command to a RTP proxy
Mar 18 01:09:31 perch /usr/sbin/ser[4076]: ERROR: send_rtpp_command:
can't send command to a RTP proxy
Mar 18 01:09:38 perch /usr/sbin/ser[4069]: ERROR: send_rtpp_command:
can't send command to a RTP proxy
Mar 18 01:09:38 perch /usr/sbin/ser[4069]: ERROR: on_reply processing
failed
I am using rtpproxy, downloaded from CVS. I downloadrf it couple of
weeks back.
[root@stingray ~]# rtpproxy -v
20040107
Is anybody else having this issue or I am doing something wrong in my
ser.cfg.
Mohammad
Hi All.
I've been toying with ideas on how to determine if a re-INVITE message
should be mediaproxy enabled or not.
I only want mediaproxy to be used if either callee __OR__ caller are
behind a NAT device. Therefore I cannot just blindly call
use_media_session() in my loose_route() logic.
There have been a few posts in the archives about possibly embedding a
NAT tag in the original INVITE message and searching for it when
processing re-INVITE messages.
Although I did get this to work I have concerns this will break some
SIP processing eventually.
So I came up with the following idea which uses AVPOPS in my
loose_route() branch. The problem is I do not know if this is legal
and/or will work in all cases.
The whole basis of this code is that a re-INVITE reverses some of the
headers in the INVITE message and the "domain" from the orignal INVITE
(ie, the caller) is still present in, but is located in the <FROM>
header. So I just copy the domain part to the RURI and
lookup(location) is called to set nat_flag 6, and finally I revert the
RURI.
So if my original INVITE message is this:
INVITE sip:4075552279@sip.mycompany.com;user=phone SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.83:39627;branch=z9hG4bKef3a7e6727dfd10d.
From: "Paul Hazlett"
<sip:3215591111@sip.mycompany.com;user=phone>;tag=3b39918cbd7276b5.
To: <sip:4075552279@sip.mycompany.com;user=phone>.
Contact: <sip:3215591111@192.168.0.83:39627;user=phone>.
Supported: replaces.
Call-ID: 46c60a9c891bc4e8(a)192.168.0.83.
CSeq: 7526 INVITE.
User-Agent: Grandstream BT100 1.0.5.22.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 396.
The re-INVITE would look like this:
INVITE sip:3215591111@66.90.46.29:39627;user=phone SIP/2.0.
Via: SIP/2.0/UDP 216.229.127.60:5060;branch=z9hG4bKd77b196c4f6-d84acd16.
Via: SIP/2.0/UDP 216.229.118.76:4060;branch=z9hG4bK01cc36bc450a3a60.
To: "Paul Hazlett"
<sip:3215591111@216.229.127.60;user=phone>;tag=3b39918cbd7276b5.
From: <sip:4075552279@sip.mycompany.com;user=phone>;tag=0682cabe.
Call-ID: 46c60a9c891bc4e8(a)192.168.0.83.
CSeq: 20292 INVITE.
Max-Forwards: 69.
Contact: sip:4075551111@216.229.118.76:4060.
Record-Route: <sip:216.229.127.60:5060;lr>.
Route: <sip:10.3.0.221:5060;ftag=3b39918cbd7276b5;lr>.
Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO.
Accept: multipart/mixed, application/sdp, application/isup,
application/dtmf, application/dtmf-relay.
Supported: timer.
Session-Expires: 240;refresher=uac.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Content-Length: 247.
Can anyone review the code snippet below and comment?
loadmodule "/usr/local/lib/ser/modules/avpops.so"
modparam("registrar", "nat_flag", 6)
route {
# sanity checks
if (loose_route()) {
if (method=="INVITE") {
# get domain portion of the <From:> header
avp_write("$from/domain", "i:30");
# save the domain portion of the RURI
avp_write("$ruri/domain", "i:31");
# replace the domain portion of the RURI with the
# domain from the <FROM> header
avp_pushto("$ruri/domain", "i:30");
# call lookup(location) to set nat_flag 6
lookup("location");
# restore the RURI
avp_pushto("$ruri/domain", "i:31");
# discard the AVPs
avp_delete("i:30");
avp_delete("i:31");
};
if (isflagset(6)) {
force_rport();
fix_nated_contact();
use_media_proxy();
};
route(1); # t_relay() the message
break;
};
# normal processing
}
route[1] {
t_on_reply("1");
if (!t_relay()) {
if (method=="INVITE" || method=="ACK") {
end_media_session();
};
sl_reply_error();
};
}
onreply_route[1] {
# Not all 2xx messages have a content body so here we
# make sure our Content-Length > 0 to avoid a parse error
if (isflagset(6)
&&
(status=~"(180)|(183)|2[0-9][0-9]")) {
if (!search("^Content-Length:\ 0")) {
use_media_proxy();
};
};
if (client_nat_test("1")) {
fix_nated_contact();
};
}
Regards,
Paul
As Jan already warned you, tomorrow , March 19, from administrative
reasons, in the whole FOKUS Fraunhofer building the power will be cut
off. So the whole FOKUS computer network will be unavailable, include
the hosted machines like berlios and iptel.
The estimated time will be from 8:00 to 13:00 CET, so be patience :-)
bogdan
When I browse the ser code, I found there are three kind of memory
allocation.The most frequently used is shm_malloc() and pkg_malloc().
the first have lock functions and the latter is not. I found that
the transaction struct cell and its field is allocated with shm_alloc,
but others are allocated with pkg_alloc(). I added a pointer member
into the cell struct. If I allocate a block of memory for my pointer
member with pkg_malloc(), the ser will crash when some one want to
establish a call through ser. If using shm_malloc(),all will go well.
What I want to know is when and where I should use shm_malloc() and
pkg_malloc().
Thanks for your instructions
Best Regards
Sun Zongjun
Hey all,
Trying to get the PA module working but I'm having some problems. From
the logs on the server:
> Mar 18 14:45:08 ser1 ser[30085]: parse_hfs(): Error while parsing headers
> Mar 18 14:45:08 ser1 ser[30085]: handle_subscription(): Error while parsing message header
> Mar 18 14:45:08 ser1 ser[30085]: handle_subscription about to send_reply and return -2
And the packets to and from SER look like this from eyeBeam's log.
ngrep confirms the messages are the correct.
> 14:45:58.4
> SENDING TO: 1.2.3.4:5060
> SUBSCRIBE sip:username2@domain.com;transport=udp SIP/2.0
> To: <sip:username2@domain.com>
> From: Evan Borgstrom<sip:username1@domain.com>;tag=5021047d
> Via: SIP/2.0/UDP 2.3.4.5:6630;branch=z9hG4bK-d87543-194995238-1--d87543-;rport
> Call-ID: 0224d4088e377630
> CSeq: 2 SUBSCRIBE
> Contact: <sip:username1@domain.com:6630;transport=udp>
> Expires: 3600
> Max-Forwards: 70
> Accept: multipart/related, application/rlmi+xml, application/pidf+xml, application/xpidf+xml
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
> Proxy-Authorization: Digest username="username1",realm="ca.mci.com",nonce="423b30d096fc2ed8a93d627c171f66b609806c17",uri="sip:username2@domain.com;transport=udp",response="30d4781a4e489da04b7606fdd22a69fb",cnonce="4d305b610573f25e",nc=00000001,qop=auth,algorithm=MD5
> Supported: eventlist
> User-Agent: MCI eyeBeam release 3004t stamp 16845
> Event: presence
> Content-Length: 0
> 14:45:58.4
> RECEIVING FROM: 1.2.3.4:5060
> SIP/2.0 400 Bad Request
> To: <sip:username2@domain.com>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-9f53
> From: Evan Borgstrom<sip:username1@domain.com>;tag=5021047d
> Via: SIP/2.0/UDP 2.3.4.5:6630;branch=z9hG4bK-d87543-194995238-1--d87543-;rport=6630
> Call-ID: 0224d4088e377630
> CSeq: 2 SUBSCRIBE
> Error while parsing headersUser-Agent: SER (0.9.0)
> Content-Length: 0
Looking through the code from subscribe.c we're looking for From:,
Event:, Expires: & Accept: all of which are present in the SUBSCRIBE
request.
> if ( (parse_headers(_m, HDR_FROM | HDR_EVENT | HDR_EXPIRES | HDR_ACCEPT, 0)
> == -1) || (_m->from==0)||(_m->event==0)||(_m->expires==0) ||
> (_m->accept==0) ) {
> paerrno = PA_PARSE_ERR;
> LOG(L_ERR, "parse_hfs(): Error while parsing headers\n");
> return -1;
> }
Anyone see this before and have a fix or work around?
-Evan
Sorry guys ... my fault ... the previous text was a screw up ...
I send it now with proper windows formatting ...
Cesc
>>> Cesc Santasusana 03/18/05 02:36PM >>>
Hi,
With the advent of TLS support for SER, i was testing it with KPhone
(TLS being used between SER proxies only, Kphone-to-SER via UDP).
Turned out that kphone would not respond to any message (it would
receive them, but plain ignore them).
The problem: TLS as transport mode in the VIA headers was not
supported,
thus, the SIP messages were considered not valid.
I am attaching a patch to correct this for kphone 4.1.0, but i guess it
can be applied
with little modifications to earlier versions (4.0.3 to 4.0.5) but i am
not sure.
Regards,
Cesc
PATCH STARTS HERE:
Index: dissipate2/sipclient.cpp
===================================================================
--- dissipate2/sipclient.cpp (revision 1)
+++ dissipate2/sipclient.cpp (working copy)
@@ -1034,6 +1034,9 @@
printf( "SipClient: Sending TCP Response\n" );
outsocket = new TCPMessageSocket;
break;
+ case SipVia::TLS:
+ printf( "SipClient: TLS in top via, not
supported (full TLS support not implemented)\n" );
+ break;
case SipVia::BadTransport:
printf( "SipClient: Bad transport on incoming
Via\n" );
break;
@@ -1232,6 +1235,9 @@
printf( "SipClient: Sending TCP Response\n" );
outsocket = new TCPMessageSocket;
break;
+ case SipVia::TLS:
+ printf( "SipClient: TLS in top via, not
supported (full TLS support not implemented)\n" );
+ break;
case SipVia::BadTransport:
printf( "SipClient: Bad transport on incoming
Via\n" );
break;
Index: dissipate2/sipvia.h
===================================================================
--- dissipate2/sipvia.h (revision 1)
+++ dissipate2/sipvia.h (working copy)
@@ -49,6 +49,7 @@
enum Transport {
UDP,
TCP,
+ TLS,
BadTransport };
/**
Index: dissipate2/sipvia.cpp
===================================================================
--- dissipate2/sipvia.cpp (revision 1)
+++ dissipate2/sipvia.cpp (working copy)
@@ -37,6 +37,7 @@
switch ( t ) {
case UDP: return "UDP";
case TCP: return "TCP";
+ case TLS: return "TLS";
case BadTransport: return "BAD";
}
return QString::null;
@@ -46,6 +47,7 @@
{
if ( t.compare( getTransportString( UDP ) ) == 0 ) { return UDP;
}
if ( t.compare( getTransportString( TCP ) ) == 0 ) { return TCP;
};
+ if ( t.compare( getTransportString( TLS ) ) == 0 ) { return TLS;
};
return BadTransport;
}
PATCH ENDS HERE
Unclassified
