Hi,
How do I make the aliases field editable in serweb. The user should
have the option of editing his aliases.
Any help in this regard, greatly appreciated.
Regards,
Santosh M Hulkund
Hello,
The FCP module for SER seems to be approaching to a stable version (no
guarranties, though). The module is in charge of 2 functions:
- Translation of SIP messages from a private network to a public one
(using NAT).
- Open and close pinholes in a firewall to allow media sessions through.
The module implements the FCP side that communicates with a deamon called
fcpd that runs on the firewall itself (developed by iptel:
http://www.iptel.org/fcp/). It seems to be reasonably stable now with cvs
version of ser from 31/03/03.
I'm looking for anyone interested in trying it and provide any feedback
(bugs, new features or complains :)).
Greetings,
Jaime
At 09:34 PM 4/6/2003, Mike wrote:
>I apologize for the terminology, I'm still learning.
Don't worry -- actually there was some confusion in what I wrote you too.
ATA may do BYE/Also, but the standard way of call-transfer is using
REFER request.
>Maybe not an "issue" with SER, but I guess what I need is a way for SER to
>get this BYE message, see the Also: and initiate another INVITE to the
>correct station, handling it like a new call?
No. What you need is standardized call transfer support in your phone.
-Jiri
Hello
Does nethelper module exist as a patch, or it's now intergrated into
ther core of SER, can anyone clarify this?
I've just mentioned 'nethelper' module in documentation, but no source
code in tree.
--
Michael Vasilenko
I've successfully installed serweb and am able to log in. However, once I
do so, I get the following error:
Warning: fopen(/tmp/ser_fifo) [function.fopen]: failed to create stream:
Permission denied in /usr/local/apache/htdocs/serweb/functions.php on line
172
at the top of the screen, and the message "sorry -- cannot open fifo" in
red letters on the webpage above the user's information. I'm wondering if
ser or apache needs to be configured somewhere with the correct
permissions or ownership to make this work.
Thanks!
Meghan Byrne
Meghan Patricia Byrne
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte705u(a)prism.gatech.edu
At 01:19 AM 4/4/2003, Mike wrote:
>I'm trying to get SER to work properly with the call forwarding feature of
>an ATA-186. The ATA-186 forwards calls (#90number#) by doing a BYE with
>an "also" header. SER doesn't seem to do anything with this at all, and
>the call just sits in limbo until everybody hangs up.
>
>Call forwarding on busy/no-answer works, but I think that's because the
>ATA is doing a refer instead.
>
>Any clue where I should be looking for this? Is SER supposed to support
>this BYE/also method, and I have something misconfigured, or is there
>additional work that needs to be done to support this?
I'm not sure what exactly happens from your narration. The terminology is
little a bit new to me -- forwarding means imho sending a 3xx reply to an
INVITE and not BYE requests. A message dump would help me to understand.
Anyway, I don't think that is an issue related to SER -- it is about
end-device features.
-Jiri
hi all,
We wanted to know whether the SER server will just Proxy the Notify method or else it gives the 200OK response also.
When we sent the Notify method, it just proxied to the contact ip address but did not send the 200OK response to us.
Thanks
Geetha
I have been testing the last changes about the "rport-received" tags, and I
have found the next bug:
when using UDP transport, if the IP address and port in the "Via" field
differ from the IP address and port of the incoming packet, the "received"
and "port" tags added to the Via of the response are correct, but the packet
is sent back to the "received" IP address BUT to an incorrect port ( this
should be the "rport" port ), that generates an ICMP "Destination
unrecheable port".
I have been capturing these packets and I think I have found exactly where
is the problem. For example in the next sequence:
1)REQUEST PACKET: ( REGISTER for example )
Source: 192.168.1.2:1667 Destination: 192.168.1.3:5060
"Via: SIP/2.0/UDP 192.168.1.100:6969;rport"
2)RESPONSE PACKET:
Source: 192.168.1.3:5060 Destination: 192.168.1.3:33542 <- HERE IS THE
PROBLEM, this should be "rport"
"Via: SIP/2.0/UDP 192.168.1.100:6969;rport=1667;received=192.168.1.2"<-but
this is correct
3)ICMP PACKET:
Source 192.168.1.2 Destination: 192.168.1.3 Type:3 "Destination unrecheable"
Code:3 "Port unrecheable"
I've been checking other pairs of ports sent and received like 1667-33542,
1507-58117, 1509-58629, 1511-59141 and the second is the network address
order of the first ( 1667 = ntohs(33542) ) .
I think that you forget to make a htons() of the port received in host
format before sending the packet back to network.
Please, let me know when this issue is solved in the CVS.
Best regards and congratulations for your excellent work.
Sergio.
fyi (in response to a frequently asked question "how to get snom's
buggy RR-ing working along with PRACK).
I just tried to create a workaournd to the problem (which is PRACK
does not put Routes learned in 183). It's as easy as mangling SIP
messages not to advertise their support for "100rel":
if (method=="INVITE" && search("User-Agent: snom")) {
#replace("PRACK, ", "");
replace("100rel, ", "");
};
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/